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(57) Abstract: A unified policy management system for an organization including a central policy server and remotely situated 
policy enforcers. A central database and policy enforcer databases storing policy settings are configured as LDAP databases adhering 
to a hierarchical object oriented stiucture. Such stnicture allows the policy settings to be defined in an intuitive and extensible fashion. 
Changes in the policy settings made at the central policy server are automatically transferred to the policy enforcers for updating 
their respective databases. Each policy enforcer collects and transmits health and status information in a predefined log format 
and u^nsmits it to the policy server for efficient monitoring by the policy server. For further efficiencies, the policy enforcement 
functionalities of the policy enforcers are effectively partitioned so as to be readily implemented in hardware. iThe system also 
provides for dynamically routed VPNs where VPN membership lists are automatically created and shared with the member policy 
enfoTceis. Updates to such membership lists are also automatically u^nsferred to remote VPN clients. The system further provides 
for fine grain access conuol of the u^affic in the VPN by allowing definition of firewall rules within the VPN. In sMition, policy 
server and policy enforcers may be configured for high availability by maintaining a backup unit in addition to a primaiy uniu The 
backup unit become acdve upon failure of the primary unit. 
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POUCY BASED NETWORK ARCHITECTURE 



FIELD OF THE INVENTION 

The present invention relates toxomputer networks, and more particularly, to-devices and 
5 methods for providing efficient, integrated and scalable policy management servicestbt remote 
private networks across the Internet. 

BACKGROU>ro OF THE IhTVENTION 

The growth and proliferation of computers and computer netwoiks allow businesses to 

10 efficiently communicate with their own components as well as with their business partners, 
customers, and suppliers. However, the flexibility and efficiencies provided by such computers 
and computer networks come with increasing risks, inclxiding security breaches from outside the 
corporation, accidental release of vital information from within it, and inappropriate use of the 
LAN, WAN, Internet, or extranet. 

15 In managing the growth of computer networks as v.^11 as addressiiig the various security 

issues, network managers often turn to network policy management services such as firewall 
protection. Network Address Translation, spam email fihering, DNS caching, Web -caching, 
virtual private network (VPN) organization and security, and URL blocking forkeeping network 
users from accessing certain Web sites through use of tiie organization's ISP, Each policy 

20 management service, however, generally requires a separate device that needs to be configured, 
managed, and monitored. Furthermorei as an organization grows.and spreads across multiple 
locations, the devices maintained also multiply, multiplying the associated expenditures and 
efforts to configure, manage, and monitor the devices. 

The solution to this problem is not as simple as just integrating multiple network policy 

25 management fimctions into a single device at each location and allowing-each location to share 
its policy information with other locations. In fact, there are many obstacles andxhallenges in 
adopting such an approach. For example, a scheme for specifying and distributing policy 
management information effectively across remote private networks of an entire organization 
generally requires a well designed object model. The synchronizing of multiple databases in the 

30 organization with updates to the policy management iirfbnnationmay also be a complex problem. 
Moreover, managing the policy information efficiently for remote devices across an organisation 
may present a challenge. Furthermore, collecting logs and statistics information from the remote 
private networks in a large distributed policy management system for efiBcient analysis and report 
generation is often a difficult task. ConventionaUy, only raw packet information is logged and 

35 saved, generally requiring time-consuming and custom-generated programs to be run on the raw 
data off-line to produce meaningftil reports and statistics. 

There are other challenges in providing a unified policy management system. For 
increased benefits, such unified policy management functions should be implemented as much 
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1 as possible m hardwav However, iHq)leinenting policy management on axhip typrcally requires 

an efficient design pi^^rtitioning. Pxatl^rmcH-e, tbe unified -policy management system •should 

allow for efficient configuration, management, and upd£rting of viitual private networks 

extending over different remote sites. 
5 Accordingly, there remains a need in the art for a networic management^olution that 

overcomes these and oilier obstacles of the prior art. 

SUMMARY OF THE INVHNTnON 

The present invention is directed to a unified policy management system where various 

1 0 policies, namely, the set of rules and instructions that determine the network'^ operation, may be 
established and enforced f om a single site. According to one embodiment of the invention, the 
system includes a first eca-r device associated with a first networic having a first'set of resources 
that is configvired to manage the policies for the first network according to the policy settings 
stored in a first database. The system also includes a second edge device associated with a 

1 5 second network having a second set of resources that is configured to manage the policies for the 
second network according to the policy settings stored in a^econd database. The first and second 
edge devices act as policy en ^brcers for their respective networks. The policies being enforced 
may include firewall polici VPN policies, and the like. 

The system fiirther includes a central policy server in communication with the fiurst and 

20 second edge devices. The policy server is configured to d^ne ibc first and second policy 
settings and manage the fibrst end second edge devices fi-om a single location. Thus, a network 
administrator need not multipiv his or her efiForts and associated expenditures inconfieuri^g and 
managing the policy enforcers individually. 

In alternative embodiments, the unified policy man^ement system includes one or more 

25 of the following features: 

The central policy serve ; may include a central database for storing configuration 
information of the policy enforcer ^. The central database as well as tbe databases associated with 
the policy enforcers are Lightweight Directory Access Protocol CLDAP) databases organized 
according to a hierarchical object oriented structure. This structure includes resource objects and 

30 policy objects for defining the policy settings for the policy enforcers. Such a structure helps 
simplify policy management by allr wing the various elements of the policy management system 
to be defined and organized in an intuitive and extensible fashioiL 

According to one embodim e nt of the invention, the resource objects include devices, 
users, hosts, services, and time. Devices are the policy enforcers at the edge of a particular 

35 private local network. Each device k associated with users and a host A host is a network (e.^. 
a LAN subnet) in an organization. rvices reflect the various services (e.^- HTTP, TELNET, 
FTP) provided by the policy server. Time is another dimension in controlling access to the 
network resources. 

-2- 



SUBSTITUTE SHEET (RULE ^6) 



€NSOOCtO: <WO. 



.0078004A3JA> 



wo 00/078004 PCT/USOO/16246 

The central database stores the coiffigur^on information, including policy settings, for 
all the policy enfcHcers. When a change is made to the configuration infcwmation, the policy 
server creates a log of -such chants and stores it in the central database for later transferring to 
the policy enforces. When the policy enforcers receive the log of x:hanges, they iqxi^e tteir 
respective databases accordingly and indicate to the policy server whether the \^ates have been 
successful. If they have been successftd, the log of changes coiresponding to these policy 
enforcers are deleted from the central database. 

The central policy server may further include a set of user application modules for 
allowing a user, such as the network administrator, to define the policy^ettings for the policy 
enforcers and further manage the policy enforcers from the single location. Prefeably, the policy 
settings are associated with a plurality of resource objects including devices, users, hcTsts, 
services, and time. 

In one aspect of the invention, the set of application modules includes a x^^ntralized 
management sub-module for allov^dng installation and registration of the policy enforcers with 
the central policy server. 

In another aspect of the invention, the ^et of application modules includes a policy 
management sub-module for managing and viewing the resource objects fix>m the single location. 

In yet a further aspect of the invention, the policy server includes a set of user application 
modules for allowing a user to monitor the health and status of the policy CTfOTcers. Each policy 
enforcer collects and transmits the health and status infomiation to the policy server in a 
predefined common log format. The policy server may then create various leports based on this 
information. It should be appreciated, therefore, that the jxesent invention allows on-the-fly 
monitoring of the resources in the organization, yielding further advantages of the invention over 
the prior art, which generally collected only raw data and required the tedious generation of 
reports. 

The functionalities of the policy enforcers in enforcing the policies for their respective 
networks may also be partitioned for effective hardware implementation. According to one 
embodiment of the invention, each edge device preferably includes a plurality of modules 
including a classification engine, a policy engine, and a packet forwarding engine. The 
classification engine determines a protocol associated with an incomii^ packet The policy 
engine makes a forwarding decision for the packet based on policy settings associated with the 
packet The packet forwarding module then forwards the padcet based on the policy settings. 

In alternative embodiments, the modiile may further include a security engine for 
authenticating a user transmitting the packet and/or a statistics module^or collecting statistics of 
packets flowing through the policy enforcer. 

Each of the networks in the system may also constitute private networks and each policy 
enforcer associated with the private network is configured to create a table with information of 
member networks reachable through the policy enforcer. The table is then shared with the other 
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1 member policy enfoFcers in the VPN. This allows thexreation of VPNs whose m^nber lists aie 
'dynamically compiled. 

In one particular aspect of the invention, the communication between theBrst andnsecond 
private networks is managed according to a security policy associated with the member networlcs. 

5 The secmity policy is preferably defined for a security policy ^group, referred to as a VPN cloud, 
providing a hierarchical organization of the group. The VPN cloud includes member networks 
(hosts), users allowed to access the member networks, and a rule controlling access to the 
member networks. The hierarchical organization provided by the VPN clouds thus allows the 
network administrator to create fully meshed VPNs where eveiy site within a VPN cloud has full 

1 0 connectivity with every other site. The network administrator need no longer manually configure 
each possible connection in the VPN, but only need to create a VPN cloud and specify the sites, 
users, and rules to be associated with the VPN. Each connection is then configured based on the 
configuration specified for the VPN cloud. The hierarchical organization thus faciUtates the 
setup of a VPN A^ath a large number of sites. 

15 In another aspect of the invention, the rule in the VPN is a firewall ride providing access 

control of the traffic among the member networks. Such firewall rules allow the administrator 
to have fine grained access control over the traffic that fiows through Ihe VPN, all within the 
realm of the encrypted access provided by such VPN. 

In a fluther aspect of the invention, a remote user accesses the member networks fi'om a 

20 remote location using a remote user terminal. The terminal is configured with software for 
downloading the table with the dynamic membership information from the edge device to which 
it is connected. Updates to the membership information are further automatically transmitted to 
the remote user terminal without requiring reconfiguration of the terminal. 

The policy server and policy enforcers, as well as other networic devices may sdso be 

25 configured for high availability by maintaining a second class imit (backup xmit) in addition to 
a first class unit (primary unit) for preventing a single point of failure. In one aspect of the 
invention, the backup unit is initially in an inactive state and later transitions to the active^state 
upon detection of a failure is the primary imit 

In another aspect of the invention, each high-availability device discovers its status as a 

30 primary imit, a backup unit, or a stand-alone unit (third class unit) during initialization. 

In a further aspect of the invention, the configiu-ation information stored in the databa^s 
of the primary and backup imits are synchronized by transitioning the first class unit to an active 
state, receiving and storing the first database configuration changes on the ^first elass unit, 
transferring the configuration changes to the second class unit, and storing the configuration 

35 changes on flie second class imit When the primary unit transitions to an inactive state, the 
backiq) imit stores the second database configuration changes on the second class unit and 
transfers those changes to the primary unit after it re-transitions to the active^te. 
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1 In still another aspect of the invention, updates to the primary and backiq) iimts,*such as 

' software updates, are also synchroni^d transmitting the update ihformationto the primary unit, 
updating the primary xmit, transmitting the update from the primary unit to the backiq) unit, and 
updating the backup unit Thus, the network adminislsrator need not duplicate his or her -efforts 

5 to update the backup imits. 

BRIEF DESCRIPTION OF THE D^WINGS 

These and other features, aspects and advantages of the present invention will be more 
fully understood when considered with respect to the following detailed description, appended 
10 claims and accompanying drawings wherein: 

FIG. 1 is a schematic block diagram of an exemplary unified policy management system; 
FIG. 2 illustrates the hierarchical object-oriented structure of policies stored for an 
organization in accordance with the principles of the invention; 

FIG. 3 is a schematic block diagram of a policy server in the policy management system 
15 of FIG. 1; 

FIG. 4 is a schematic diagram of a central management sub-module in the policy server 
of FIG. 3; 

FIG. 5 is an exemplary flow diagram of a device registration process -carried out by the 
central management sub-module of FIG. 4; 
20 FIG. 6 is a screen illustration of an exemplary graphical user interface for registering a 

device; 

FIG. 7 is a screen illustration of an exemplary global monitor user interface presentiiig 
device health and status information; 

FIG. 8 is a screen illustration of an exemplary graphical user interface provided by a 
25 policy management sub-module in the policy server of FIG, 3; 

FIG. 9 is a screen illustration of an exemplary graphical user interface for managing 
system devices; 

FIG. 10 is a screen illustration of an exemplary graphical user interface for managii^ 
system hosts; 

30 FIG. 11 is a screen illustration of an exemplary graphical user interface for managing 

system services; 

FIG. 1 2 is a screen illustration of an exemplary ^phical user interface for managing time 

groups; 

FIG. 13 is a screen illustration of an exemplaiy graphical user interface displa3dng a 
35 plurality of VPN clouds; 

FIG. 14 is a screen illustration of an exemplary graphical user interface for adding a new 
firewall policy; 
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1 FIG. 15 is a sdiematic functional block diagram ctf policy '^ososss vjfddSit^ their 

respective VPN membCTship information; 

FIG. 1 6 is a block diagram ofcomponents in aself-extracting executable for doAvnloading 
by a remote VPN client; 

5 FIG. 1 7 is a functional block diagram for downloading theTself-^extracting executable of 

FIG. 16; 

FIG. 18 is a schematic block diagram of a policy enforcer in the policy management 
system of FIG. 1; 

FIG. 19 is a more detailed schematic block diagram of a policy engine in the policy 
1 0 enforcer of FIG. 1 8; 

FIG. 20 is a more detailed schematic block diagram of a protocol classification engine of 
the policy enforcer of FIG. 18; 

FIG. 2 1 is a more detailed schematic block diagram of an Internet protocol^urity engine 
in the policy enforcer of FIG. 18; 
15 FIG. 22 is a schematic layout diagram of a common log format according to one 

embodiment of the invention; 

FIG. 23 is a block diagram of an LDAP tree structure aocordii^ to one CTibodiment of 
the invention; 

FIG. 24 is a more detailed block diagram of a branch of the LDAP tree of FIG. 23; 
20 FIG. 25 is a flow diagram for logging and propagating LDAP changes to policy eufprcers; 

FIG. 26 is a schematic block diagram of a high availability system includii^ a primary 
unit and a backup imit; 

FIG. 27 is a flow diagram of an exemplary status discovery process conducted by a high 
availability imit; 

25 FIG. 28 is a flow diagram of a process for maintainirig configuration information 

synchronized in the primary and backup units of FIG. '26; 

FIG. 29 is an exemplary flow diagram of updating the primary and backup units of FIG. 
26 when they are both functional; and 

FIG. 30 is an exemplary flow diagram of updating the primary and backup units FIG. 26 
30 when the primary is not functional. 

DETAILED DESCRIPTION OF THE INVENTION 

I. UNIFIED POLICY MANAGEMENT SYSTEM ARCHITECTURE 

FIG. 1 is a schematic block diagram of an exemplary unified policy man^ement system 
35 according to one embodiment of the invention. As illustrated in FIG. 1, private loical networks 
102, 104, and 106 are all coupled to a public network such as the Internet 108 via respective 
routers (generally identified at 1 10) and Internet Service Providers (ISPs) jCnot shown). Also 
coupled to the public Internet 108 via the ISPs are w«b surfers 1 12, dial-ujp network users 1 14, 
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1 servers providing imarrthorized web sites H6, email jammers 1 18 sending out unsolicited junk 
email, and remote VPN clients 140 ^seeking access to the private local networks 1 02. 

According to one exan^le, local network 102-connects users and resources, -such 
as workstations, servers, printers, and the like, at a first location of the organization, such as the 

5 organization's headquarters, and local network 104 connects users and jesoinces at a second 
location of the organization, such as a branch ofl5ce. Furthermore, local network 106 connects 
users and resources of a customer of tiie organization requiring special access to the 
organization's users and resources. Authorized dial-iq) netwoik users 1 14 of the oi^anization 
are respectively situated at remote locations from the first and second local networks, and also 

10 require special access to the organization's users and resources. Furtheraiore, web surfers 1 12 
communicate with the organization's web server 120 over the public Internet 1 08 and access the 
organization's web site. 

Local network 102 includes a policy server 122 for defining and managing network 
services and policies for the organization. The network policies are aiset of rules and instructions 

15 that determine the network's operation, such as firewall, VPN, bandwidth, and administration 
policies. The firewall policies decide the network traffic that is to be allowed to flowfi-om the 
public Internet 108 into the local networks 102, 104, and the traffic that is to be blocked. The 
bandwidth policies determine the kind of bandwidth Aat is to be allocated to the traaBSc flowing 
through the local networks. The VPN policies determine the rules for implementing multiple site 

20 connectivity across the local networks. The administration policies dedde the users that have 
access to administrative functions, the type of administrative functions allocated to these users, 
and the policy enforcers 124, 126 on which these users may exercise such administrative 
fimctions. The firewall, VPN, bandwidth, and administration policies for the entire organization 
are preferably stored in a policy server database 130 maintained by the policy server 122. 

25 Each local network 1 02, 1 04 also includes an edge device, referred to as a policy enforcer 

124, 126, for controlling access to the network. Each policy enforcer 124, 126 manages the 
network policies and services for the users and resources of their respective local networks 102, 
1 04, as permitted by the policy server 1 22. Respective portions of the policy server database 130 
are copied to the policy enforcer databases 132, 134 for allowing the policy enforcers to manage 

30 the network policies and services for the local networks 102, 1 04. 

According to one embodiment of the invention, the policy server 1 22 and policy enforcers 
124, 126 may be implemented in a sunilar fashion as the FORT KNOX series of policy routers 
made by Alcatel Internetworking, Inc., of Milpitas, California. 

35 n. OBJECT MODEL FOR NETWORK POLICY IVUNAGEMENT 

According to one embodiment of the invention, the policy server database 130 and policy 
enforcer databases 132, 134 are LDAP databases adhering to a unified hierarchical object 
oriented structure. The LDAP directory service model is based on entries where -each «itry is a 
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1 collection of ^tributes i^ereneed by a distinguished name^IM^. Each of flie attributes includes 
a type and one or more values. Hie type is typically a mnCTionic string, -such as -o" for 
organization, "c" for country, or "mail" for email address. The values depend on the type of 
attribute. For example, a '*mail" attribute may x:ontain the vsdue ''bab^^umichsedu.'' A 
3 "jpegPhoto" attribute may contain a photograph in binary JPEG/JFIF format Additional details 
of tiie LDAP directory service model are defined in RFC 1777 "The Ligjhtweight Directory 
Access Protocol" (W. Yeong, T. Howes, and Kille, Network Working Group, March 1 995) and 
"LDAP Programming: Directoiy*enabled Applications with Lightweight Directory Access 
Protocol" (T. Howes, and M. Smith, Macmillan Technical Publishing, 1997), incorporated herein 

10 by reference. 

The entries in the LDAP database are preferably arranged in a hierarchical tree-like 
structvire reflecting political, geographic, and/or organizational boimdaries. Entries representing 
countries appear at the top of the tree. Below them are entries representing states or national 
orgam2ations. Below the states or national organizations may be entries representing people, 

15 organization \mits, printers, documents, and the like. 

FIG. 2 is a schematic layout diagram of a unified hierarchical object oriented structure 
adhered by the policy server database 130 according to one embodiment of tilie inventiorL The 
policy enforcer databases 132, 134 adhere to a similar structure except for a few dififerences. For 
example, the policy enforcer databases preferably do not contain a policy server domain object 

20 201 and related policy server objects, nor a policy domain object 240. 

As illustrated in FIG. 2, each object in the structure is preferably stored as an LDAP entry. 
At the top of the hierarchy is the policy server domain object 201 including various policy server 
resources and a plurality of policy domains objects (generally referenced at 204). Each policy 
domain object 240 is a grouping of policy enforcers that share common policies. Each policy 

25 domain object 240 includes a resource root object 200 and a group root object 202. All policy 
management functions are preferably implemented in t^ms of the resource objects which include 
devices 204, users 206, hosts 208, services 210, and time 220. Thus, a firewall policy may be 
defined by simply assigning the particular devices, users, hosts, services, and time applicable to 
the policy. The devices, users, hosts, and services are preferably organized in -groups 212, 214, 

30 216, and 218, respectively, having a group name, description, and member information for a 
more intuitive way of addressing and organizing the resources. 

Users 206 are preferably associated with a user domain pro\dding a secure and efficient 
means of authenticating the user. Each user domain has a single policy enforcer who is authorized 
to authenticate the user. Thus, user domains ensure that the authenticating s^ent is generally 

35 located in the same local network as the user. This helps eliminate the cost of network 
dependency or network latency during the user authentication process. It should be noted, 
however, that users may also constitute authorized dial-up us^ 114 and users fix)m the customer 
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1 netwoik 1 06. These us^ contact a remote autfaentic^ng s^ent whichproxies &e authentication 

back to the appropriate policy enforcer. 

Hosts 208 are the various networks pr^ent in an c^ganization. For instance, a particniar 

LAN subnet may be specified as a host in the system. Hosts 208 are preferably organized based 
15 on their physical locations within the organization. A host' s physical location is identified by the 

device (policy enforcer) 204 associated with the host 

Services 210 reflect the various services provided by the policy servo: 1 22. Such services 

include, for example, multimedia streaming/conferencing, information retrieval, security and 

authentication, database applications, mail applications, routing applications, istandard 
10 communication protocols, and the like. Attributes associated with each service preferably 

include a service name, description, type (e.g. HTTP, HTTPS, FTP, TELNET, SMTP, Real 

Networks, and the like), and group. 

Devices 204 are the policy enforcers 124, 126 at the edge of a particular local network. 

Each device/policy enforcer preferably includes users 206 and a host/network 208 that is 
15 managed by the policy enforcer. 

Time 220 is another dimension in controlling access to the network resources. Various 

time objects covering a range of times may be created and used in creating the firewall policies. 
Similar to resources, network policies are also preferably defined in terms of objects fdr 

a more efficient and intuitive definition of the policies. Policies are defined by the administrators 
20 and implemented by the policy enforcers 124, 126 on the network traffic flowiiig between the 

public Internet 108 and the local networks 102 and 104. 

According to one embodiment of the invention, a policy object 222 includes a bandvddth 

policy 224, firewall policy 226, administration policy 228, and VPN policy 230. The VPN policy 

230 defines a secxirity policy for the member networks and includes one or more VPN clouds 
25 232. Each VPN cloud 232 is an individual VPN or a group of VPNs defining a security policy 

group which includes a list of sites 234 and users 236 who can conmiunicate with-each other. 

A site is preferably a set of hosts/networks physically located behind one of the policy enforcers 

124, 126. In other words, a site is a definition of a networit which includes the policy enlorcOT 

that is associated with it. The policy enforcers for the sites act as VPN tunnel endpoints once fbc 
30 hosts under the sites start communicating. These conununications are govraned by a set of rules 

238 configured for each VPN cloud. The rules 238 may govern, among otiier things, VPN acctes 

permissions and security features such as the level of encryption and authentication used for the 

connectivity at the network layer. 

The object oriented structure of FIG, 2 thus allows the network administrators to define 
35 policies in an intuitive and extensible fashion. Such policies may be defined by simply 

associating resources to the policies. This allows for a policy-centric management model where 

the administrator is given the impression that a single logical server provides the firewall. 



-9- 



SUBSTITUTSE SHEET-(RULE 26) 



3NSOOCIl>: <WO. 



.0078004Ad.lA> 




wo 00/078004 PCTAJSOO/1 6246 

1 bandwidth management, and VPN swvices across the -enterprise. The feet that &e policy is 
enforced on individual policy enforcers in different locations is transparent to the administrator. 

m. POLICY-BASED NETWORK ARCHITECTURE 

5 FIG. 3 is a more detailed schematic block dia^am of the policy -servo: 132 according to 

one embodiment of the invention. The policy server 122 preferably includes a management 
module 302 that allows centralized control over the policy -enfi^cers 124, 126 &om a single 
console. The policy server 122 further includes a log collecting and archiving module 304 and 
a policy server reports module 316. The log collecting and archiving module 304 collects 

10 information about the status and usage of resources from the policy enforcers 124, 126 as v^ll 
as from the management module 302, and stores them in an archive database 3 18. The policy 
server ret^orts module 316 uses the collected logs and archives tO:gramte reports in an organized 
report format. 

Referring again to the management module 302, the management module 302 preferably 
15 includes four sub-modules aiding in the centralized control, namely, a centrali^^ management 
sub-module 306, policy management sub-module 308, secure role-based management sub- 
module 310, and multiple site coimectivity management sub-module 312. 

The centralized management sub-module 306 enables a network administrator to install 
and manage individual policy enforcers from a central location. The network administrator 
20 preferably uses a web-based graphical user interface to define the policy enforcer's network 
configuration and monitor various aspects of the device, such as device healA, device alarms, 
VPN connection status, and the like. 

The policy management sub-module 308 provides the network administrator with the 
ability to create policies that span multiple functional aspects of the policy enforcer<e.g. firewall, 
25 bandvsddth management, and virtual private networks), multiple resources {e^g, iisers, hosts, 
services and time), and multiple policy enforcers. 

The secure role-based management sub-module 310 provides role-based management to 
enable administrators to delegate administrative responsibilities to other administrators. This 
sub-module preferably provides for maximum security v^n it comes to accessing the 
30 management fiinctions. 

The multiple site coimectivity management sub-module 312 allows the network 
administrator to set-up secure communication channels between two or more remote sites. In 
doing so, this sub-module leverages the centralized managenoent sub-module 306, polix^ 
management sub-module 308, dynamic routing capabilities of thepolicy^nforcers 124, 126, and 
35 the management infrastructure to provide virtual private networks across the enterprise widi'fine 
grained access control. 

FIG. 4 is a more detailed schematic diagram of the central poUcy management sub- 
module 306 according to one embodiment of the invention. The sub-module includes a policy 
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1 server installatioB wizard 404 providing an interactive user interfaceto aid the installationx)rthe 
policy server 122. In this regard, the network administrator has access to a personal computer 
connected to a LAN port of the policy sender 122 via a cross over^ble, hub, or the like. The 
network administrator connects to the policy server 122 by preferably typing-in a URL of the 

5 policy server 1 22 into a standard Internet browser mich as Microsoft Internet l&cplorer. The URL 
is preferably of the form of ''http://<ipaddiess>:88/index.html" where <ipaddress> is flie IP 
address that is to be assigned to the'policy server. The IP address is automatically assigned to 
the policy server when the browser attempts to contact the address. When &e administrator's 
personal computer sends an address resolution protocol request for the IP address, the policy 

1 0 server detects that a packet directed to port 88 is not claimed, and assumes the IP address. 

Once connected, the policy ser\er installation wi^d 404 invokes the interactive xiser 
interface to assist the administrator in setting up the policy server 122. Among other things, the 
policy server installation wizard 404 prompts the administrator to specify a server name, server 
IP address, and router IP address. Furthermore, the policy server installation vozard 404 prompts 

15 the administrator to select one of various default policies for creating default firewall, VPN, 
bandwidth, and administrator policies. These policies are then replicated on each new policy 
enforcer registering with the policy servo: 122. 

The centralized management sub-module 306 further includes a policy enforcer 
. installation wizard 406 providing an interactive usct interface to aid the installation of the policy 

20 enforcers 124, 126. As with the installation of the policy server 122, the access to the wizard 406 
is preferably web-based using the network administrator's personal computer. 

Once connected, the policy enforcer installation wizard 406 invokes the int^acti ve user 
interface to assist the network administrator in setting up a particular policy enforcer 124, 126. 
Among other things, the policy eriforcer installation wdzard 464 prompts the administrator to 

25 specify the policy server IP address, policy enforcer IP address, and router IP address. The policy 
enforcer then registers vdth the policy server 122 by invoking a URL on the poUcy server with 
basic bootstrap information of its own. The registration of the policy enforcer allows the 
initialization of the policy enforcer's database 132, 134 with the configuration information, as 
well as the monitoring of the policy enforcer's status and health by the policy server 122. 

30 Prior to registering the policy enforcer with the policy serv» 122, &e network 

administrator preferably pre-registers the policy enfoico: on the policy server. Such j»e- 
registering allows the creation of a placeholder node on the policy server for flie policy enforcer 
data for when the policy enforcer does in fact register. In this regard, the centralized management 
sub-module 306 includes a cormgiu^tion interface 410 allowing the pre-registration of a new 

35 policy enforcer. 

FIG. 5 is an exemplary flow diagram of a policy enforcer pre-registration and registration 
process according to one embodiment of the invention. In istep 401, the policy enforcer is 
connected to the network and installed at its actual physical location using the above^scribed 
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policy enforoer installation wizard406. The r etworlc administrator, possessing Ibe new tlevice's 
serial number, pre-registers the policy enforcer by adding the new policy CTsfoiceac to a device 
group in step 403 . In this regard, theconSgviration interface 410 invokes an interactive :@:aphical 
interface, such as the one illustrated in FIG. 6, allowing the network administrator to -enter a 
device name 415, serial number 417, and location information 419, and furOier allowing Ae 
administrator to select a device group 421 to which the new policy ^enforcer is to belong. 
Actuation of an apply button 423 causes the ecw policy enforcer, in step 405, to contact the 
policy server 122by preferably invoking a URL on the policy server. Once the policy-server has 
been contacted, the new policy enforcer transmits its rejgistration padcet to the i>olicy server. The 
registration packet includes at least a serial number of the new policy enforcer, as well as the IP 
addresses of the LAN, WAN, and DMS on the policy enforcer. In step 407, the centralized 
management sub-module 3 06 compares the serial number of die new policy enforcer with the list 
of policy enforcers pre-registered with the polic} server 122. If a match is foimd, the policy 
server 122 proceeds with the registration process by packaging, in step 409, the settings selected 
for the policy enforcer during its installation process, preferably into an LDAP Data Interchange 
Format Qdif) file. In step 41 1, the file is transmitted to the policy enforcer, preferably over an 
HTTPS charmel, by invoking a common gateway i nterface (CGI) on the policy enforcer. The 
policy enforcer then uses the file to initialize its cc':ifiguration database, such as database 132, 
134, in step 413. 

Referring again to FIG. 4, the centralized management sub-module 306 also includes a 
global monitor usct interface 402 and a data collector program 412, respectively displaying and 
collecting the health and status of all the policy enforcers managed by the policy server 122, The 
data collector program 412 receives health and status information from each of the up-and- 
running policy enforcers it manages, and passes the relevant information to the global monitor 
user interface. A health agent running as a daemon in each of the policy enforcers being 
monitored periodically collects data from the device and analyzes its health status. The collected 
data is then transferred to the policy server 122 when requested by the data collector program 
412. 

FIG. 7 is a screen illustration of an exemplaiy global monitor user interface 402 
presenting various types of health and status information. Such information may relate to the 
health of the device, such as system load 712 and network usage information 714. The 
information may also relate to current alarms 716 on The device including alarm name, type, 
description, and the like. The information may further relate to current VPN connections 718 
including connection type, source/destination, duration, and VPN traffic volume. 

Referring again to FIG. 3, the policy managem :nt sub-module 308 allows for policy 
management of the policy enforcers 124, 126. As dis::ussed above, all policy mana^gement 
functions are implemented in terms of resource objects stored in the poUcy databases 13t), 132, 
134 including users, devices, hosts, services, and time. Preferably, all resources are associated 
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1 >vitfa default policy settings selected by the administrate during ihe installation proeess. The 
network administrator views, adds, and modiSes the policies centrally via a graphical user 
interface provided by the policy management ^b*module 308. This allows for a policy-xjentric 
management model where the administrator is given the impression that a single logical server 
5 provides the firewall, bandwidth management, and VPN"services across the enterpwise. The fact 
that the policy is enforced on individual policy enforcers in different locations is transparent to 
the administrator. 

FIG. 8 is a screen illustration of an exemplary graphical user interface provided by the 
policy management sub-module 308. The interface includes a resource palette 71 8 including a 

1 0 list of resource tabs including a users tab 71 8a, devices tab 71 8b, hosts tab 71 8c, services tab 
71Sd, and time tab 71 8e, The resource palette allows the administrator to add and niodify 
resource definitions from a single console. 

Selection of the users tab 71 8a causes a display of the user groups 722 defined for the 
system. New users may be added to the group by selecting a particular group and defining 

1 5 various attributes of the user such as a login name, full name, policy enforcer to which the user 
belongs, authentication scheme, password, and the like. 

Selection of the devices tab 71 8b causes a display of various device management icons 
for managing the policy server 122 and the policy enforcers 124, 126 as is illustrated in FIG. 9. 
A policy server systems settings icon 750 allows the network administrator to view and modify 

20 system settings like LAN, WAN/DMS DP addresses of the policy server 122. A policy server 
archive options icon 752 allows specification of reporting and other database archive options at 
the policy server 122. A global URL blocking icon 754 allows the administrator to specify a list 
of unauthorized web sites 1 16 to be blocked by all the policy enforcers 124, 126 of the system. 
Similarly, a global spam list icon 756 allows the administrator to specify a list of email addresses 

25 of spammers 1 1 8 to be blocked by all the policy enforcers. 

The administrator may view information on all the policy enforcers 1 24, 1 26 by selecting 
icon 758. Information on a specific policy enforcer may be viewed by selecting a^pecific policy 
enforcer 760 under a particular device group 761. Such information includes system settings 
information 762, URL blocking information 764, spam list information 766, and the like, that is 

30 specific to the selected policy enforcer. For instance, selection of the policy enforcer's URL 
blocking information 764 icon causes a display of various categories 768 of URLs that the 
network administrator may select to block for ihe selected policy enforcer. 

Selection of the hosts tab 7 1 8c causes a display of various hosts (networks) of the system 
as is illustrated in FIG. 10. A host is organized based on its physical location and is fiirther 

35 associated with aparticular policy enforcer 1 24, 1 26. Hosts are associated with various attributes " 
including a um'que name 770, an IP address of the network 772, and a subnet mask 774. In 
addition, the administrator may specify whether the host is an extemal host 776 belonging to a 
network that is not administered by the policy server 122. If the host is an external host, the 
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1 administrator specifies an IP addi^s 778 of the external iJevice to which the host belorgs. A 

device field 780 allows the administrator to^nter the policy enforcCT's name to Avhich the host 
belongs. Each host is further associated with a particular group 782 assigned by the 
administrator. 

5 Selection of the services tab 718d causes a display of various^ervicegroi5>s supported 

by the policy server 122 as is illustrated in FIG. 1 L Such service gro\q)s include, for example, 
multimedia streaming/conferencing, information retrieval, security and auttentication, mail 
applications, routing applications, database applications, standard communication protocols and 
the like. Users may also add new service groiq)s as desired. 

1 0 Each service is associated with a name 784, description 786,. and service type 788 (e.g. 

HTTP, HTTPS, FTP, TELl^ffiT, SMTP, Real Networks, and the like). Furthermore, each service 
is associated with a service group 790. Based on the type of service, additional information may 
also be specified for the service. For instance, for an HTTP service, the administrator may 
specify whether URL blocking 792 is to be enabled. 

1 5 Selection of the time tab 7 1 8e causes a display of various time -group icons 794 covering 

a range of times to be used in the firewall policies as is illustrated in FKj. 12. For instance, 
selection of a work time group icon allows the network administrator to set the days and times 
which are to be set as working days and hours. 

Referring again to FIG. 8, the interface also includes a policy canvas 720 including a list 

20 of policies available to the system. A policy definition is preferably an association of a set of 
resources that may be dragged fi-om the resource palette 718 and dropped onto the policy canvas 
720. 

Selection of a firewall tab 720a causes a display of all the firewall policies defiled for a 
particular policy domain including one or more policy enforcers. The netwoik administrator 

25 decides the domain to which a policy enforcer is to belong during pre-registration of the policy 
enforcer. The interface allows the network administrator to view, add, and modify the various 
policies from the policy server 122 and effectuate the changes on the poliqr enforoeis 124, 126 
without the need to make such changes individually in each policy enforcer. 

According to one embodiment of the invention, each firewall policy includes a policy 

30 identifier (ID) attribute 724 for identifying a particular policy rule in the list of policies. An order 
number attribute 726 for the policy rule indicates the sequence in which the policy is to be 
applied. In this regard, the policy enforcer 1 24, 1 26 for the local network takes one rule at a time, 
in sequence, compares it against the network traffic, and preferably applies the first rule that 
matches the network trafiSc. 

35 Each firewall policy also includes a description attribute 728 for describing the firewall 

policy to be applied. For instance, the description may indicate that the policy allows spam 
blocking, URL blocking, VPN key management, and the like. An action flag attribute 730 
indicates whether traffic is to be allowed or denied for the indicated policy. An active flag 

-14- 



-SUBSTITUTE SHEET (RULE 26) 



MSDOCIO: <WOL 



.0078004A3.IA> 





wo 00/078004 



PCTAJSOO/16246 



attribxite 732 indicates whether the policy has-been activated or tie-activated. Thus, the n^work 
administrator may create a policy and activate it at a later time. A policy that has been de- 
activated preferably has no effect on the network traffic. 

Each firewall policy further includes a user attribute 734, source attribute 736, service 
attribute 738, destination attribute {not shown), and time attribute (not shown). Each of ti^se 
attributes is preferably represented by a group name or a resource name. The name acts as a 
pointer to an entry in the group root object 202 or resource root object of the LDAP database 1 30, 
132, or 134. 

Preferably, the user attribute 734 indicates the user^oups and users that are eligible for 
the policy. The source attribute 736 indicates a point of origination of the network traffic 
associated with the user. The services attribute 738 indicates the services to the allowed or 
denied by the policy. The destination attribute indicates a specific LAN, WAN, DMS segment 
or specific hosts where the specified services are to be allowed or denied. For example, to 
configure SMTP pop services on a mail server, the host may be the IP address where the mail 
server is running, and the services specified is^MTP. The time attribute indicates a time slot in 
which the policy is to be effective. 

In addition to the above, each firewall policy also includes an authentication attribute (not 
shown) indicating an authentication scheme for the policy {e.g. none, LDAP, BecurlD, RADIUS, 
WinNT,orall). 

FIG. 14 is a screen illustration of an exemplary graphical user interface for addii^ a new 
firewall policy to the policy domain upon actuation of an add button 725. Existing Brewall 
policies may also be modified or deleted by actuation of a modify button 727 and a delete button 
729, respectively. 

As illustrated in FIG. 14, a new firewall policy may be defined by simply adding a 
description of the policy in a description area 728a, selecting an action to be applied to the 
matching network traffic in an action box 730a, and indicating in an active area 732a whether the 
policy is to be active or inactive. Furthermore, the network administrator specifies the user, 
source, services, destination, and time resources in a user area 734a, source area 736a, services 
area 738a, destination area 739a, and time area 741, respectively. The network administrator 
further selects an authentication scheme for the policy in an authentication area 743. Upon 
actuation of an OK button 745, appropriate entries of the policy server database's LDAP tree are 
suitably changed to reflect the addition of the new policy. The change is also transmitted to the 
respective policy enforcers as is described in fiirther detail below. 

Referring again to FIG. 8, selection of the bandwidth tab 720c allows the display, 
addition, and modification of various bandwidth policies determining the kind of bandwidth to 
be allocated to a traffic flowing through a particular policy enforcer. DiSerent bandwidths may 
be specified for different users, hosts, and services. 
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^Selection of the administration tab 720d allows the display, addition, and modiScation 
of various administrative policies allo>ving a head network administrator to deleg^ 
administrative responsibilities to other administrators. In this regard, the head network 
administrator specifies administration policies that determine which users have access to what 
functions, and for v/hat devices. Preferably the administration policies include similar attributes 
as the firewall rules except for the specification of a role attribute. Extra administrative 
privileges may be afforded to certain users depending on their role. 

IV. VIRTUAL PRIVATE NETWORK HAVING AUTOMATIC 
REACHABILITY UPDATING 



Referring again to FIG, 3, the multi-site connectivity management module 312 allows the 
creation of dynamically routed VPNs where VPN membership lists are automatically created 
without statically configuring the membership information by the network administrator. Thus, 
once the administrator configures a VPN fi-om one policy enforcer's LAN to another, routing 

15 protocols such as RIPvl or RIPv2 ruiming on the LAN interfaces learn about the networks 
reachable through their respective interfaces. These networks then become the VPN's members, 
and the policy enforcers 124, 126 on either side of the VPN create membership tables using the 
learned routes. Tlie membership information is preferably exchanged between the policy 
enforcers 124, 126 through the LDAP databases 132, 134. Thus, the combined use of routing 

20 protocols and LDAP allows the creation of VPNs whose member lists are dynamically compiled. 

Referring again to FIG. 8, the network administrator configures VPN policies for multiple 
site connectivity using the resource palette 718 and policy canvas 720. Selection of the VPN tab 
720b in the policy canvas 720 causes the display of a collection of VPN clouds 270 already 
configured for the system as is illustrated in FIG. 13. As described above, a VPN cloud is an 

25 individual VPN or a group of VPNs for which a seciuity policy may be defined. Each VPN cloud 
includes a list of sites imder a sites node 234 and tisers under a users node 236, who can 
communicate with each other. A site is a set of hosts that are physically behind one of the policy 
enforcers 124, 126. The policy enforcers for the sites preferably act as VPN tunnel endpoints 
once the hosts under the sites start communicating. 

30 The users in the VPN cloud are the users who may access the hosts associated with the 

sites 234. The users access the hosts as VPN clients using VPN client software installed in each 
user's personal computer as is described in further detail below. 

Each VPN cloud 270 further includes a firewall rules node 276 including firewall rules 
to be applied all the connections in the cloud. The rules may govern, among other things, VPN 

35 access permissions, security features such as the level of encryption and authentication used for 
the connectivity at the network layer. 

The hierarchical organization provided by the VPN clouds thus allows the network 
administrator to create fiilly meshed VPNs where eveiy site within a VPN <:loud has fiill 
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1 connectivity with every other site. The network administotor need no longer manually coiifi€;vH:e 
each possible connection in the VPN, but only need to create a VPN cloud and Specify the sites, 
users, and rules to be associated with the VPN, Each connection is then configure based on the 
configuration specified for the VPN cloud. The hierarchical organization thus facilitates the 
5 setup of a VPN with a large number of sites. 

The network administrator preferably adds a new VPN cloud by actuating an add button 
280. In response, the policy server 122 automatically <areates the sites node 272, users node 274, 
and rules node 276 under the VPN cloud. The administrator then specifies the sites and users in 
the VPN. 

1 0 According to one embodiment of the invention^ the rules node 276 initiaUy includes a 

default VPN rule 278 corresponding to the policy settings selected by the network administrator 
during setup of the policy server 122. The default VPN rule 278 allows unrestricted access 
between the hosts in the VPN. 

The administrator may implement the access control within the VPN cloud by deleting 

15 the default rule 278 and adding specific firewall rales to the VPN. Such firewall rules allow the 
administrator to have fine grained access control over the traffic that flows through the VPN, all 
within the realm of the encrypted access provided by such VPN. The firewall rules are applied 
to the cleartext packet after it is decrypted or before it is encrypted. 

According to one embodiment of the invention, the administrator selects the default rule 

20 278 to effectuate such changes to the default rule. Selection of the default rule invokes a 
graphical user interface similar to the one illustrated in FIG. 8. The network administrator then 
fine tunes the access to the VPN by defining the firewall rules applicable to the VPN. The 
parameters in these firewall rules are preferably identical to tfaegeneral firewall rules illustrated 
in FIG. 8. 

25 Once a VPN cloud is configured, VPN membership information is dynamically created 

by the policy enforcers 124, 126 in the VPN. In this regard, each VPN site includes a tag 
identifying the hosts included in the site. At runtime, the policy enforcers 124, 126 for the 
respective sites associate IP addresses to the tag identifying the hosts in each site. Ihis allows 
the IP addresses to be dynamically discovered without requiring static configuration of the IP 

30 addresses. 

After the creation of the membership tables, any changes in the routing infcnmation is 
detected and notified to the member policy enforcers using a publish/subscribe process. The 
actual changes are retrieved by a policy enforcer by querying the LDAP database on the particular 
network that corresponds to the changed routing information. 
35 FIG. 1 5 is a schematic functional block diagram of policy enforcers 1 24, 126 at opposite 

ends of a VPN tunnel updating their respective routing information. As illustrated in FIG. 15, 
each policy enforcer 124, 126 includes a gated module 252, 261 configured as a daemon to run 
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1 one or more routing protocolsfor-exchai^ing routes on the netw 
include RIPvl, RIPv2, OSPF, and the like. 

When a network administrator wishes to add a new route to the private local network 102 
connected to policy enforcer 1 24, the administrator submits, in step 241 , the new route to agated 

5 module 252 in the policy enforcer 124. This is typically done by configuring a downstream of 
the policy enforcer to have an additional network- This information is then propagated by 
standard routing protocols to the gated module 252 of the policy enforcer 124. For example, the 
policy server 122 may publish the new route to the policy enforcer 124 with vMch the new route 
is to be associated. The route may be specified, for example, by an LDAP statement such as 

1 0 "LAN_Group@PRl which specifies a new route firom a policy enforcer PRl to a LAN named 
LAN_Group. The gated module 252, in step 242, writes the new route to a kernel 253 of the 
policy enforcer including a VPN driver 254 so that the policy enforcer 124 can properly direct 
appropriate messages along the new route. Furthermore, the ^ated module 252, in step 243, 
writes the new route to its LDAP database 132. 

15 The gated module 252 also provides, in step 244, the name of the new route to a 

distinguished name monitor (DNMonitor) daemon 255 configured to listen for updates in the 
LDAP database 1 32. The DNMonitor in turn notifies, in steps 245a, 245b, a VPN daemon 256 
and a policy deployment point (PDF) engine 257 of the change in the LDAP database 132. The 
PDF engine then updates the modules that enforce the policies, with the chaste. 

20 The VPN daemon 256, in step 246, uses the route name to TOcess the LDAP database 1 32 

to get the complete route information, a list of all VPNs to which the new route belongs, and a 
list of all other policy routers connected to tihose VPNs. In step 247, the VPN daemon 256 
proceeds to send the new route name to each of the other policy routers. 

When policy router 126 receives a new route name fi-om policy router 124, its network 

25 daemon 258, in step 248, accesses the LDAP database 132 in the sending policy router 124 to 
obtain the complete new route information. If the new route belongs to more than one VPN and 
has different parameters for the different VPNs, routers on the different VPNs retrieve different 
information corresponding to the individual VPNs. 

In step 249, the network daemon 25 8 writes the newroute information obtained in its own 

30 LDAP database 134 and provides it to its own DNMonitor module. As in the sending policy 
router 124, the DNMonitor module 259 in the receiving policy router 126 provides the new route 
information to its PDF engine 260 for updating its kernel 265 with the latest changes. 

Although FIG. 1 5 has been described in connection with addition of a route to a policy 
enforcer and its associated VPNs, it should be readily apparent to those skilled in the art that 

35 essentially the same techniques may be applied to deletion of a route (for example, if a network 
component becomes inoperative or incommunicative), or change of a route<the policy router may 
recognize that a route aheady exists in a different form and simply overwrite it). In this way, the 
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VPN system or systons can dynamically maintain routing inibrmation between its policy 
enforcers with minimal intervention by the system administrator. 



V. VIRTUALPRIVATENETWORKHAVING AUTOMATIC UPDAXmG OF 
CLffiNT REACHABILITY INFORMATION 

Remote users communicate over the public Intemet 1 08 with the other members of the 
VPN behind policy enforcers 124, 126, upon presenting appropriate credentials. These remote 
users access the private networks as VPN clients 1 40 using a VPN client software. Atx:ording to 
one embodiment of the invention, the system allows the remote user to download a self- 

10 extracting executable v^^iich, upon execution, installs both the VPN client software and VPN 
reachability information unique to the remote user in the user's remote terminal. 

Each policy enforcer 124, 126 preferably maintains a copy of the ^elf-extracting 
executable of the VPN client software including a setup program and VPN reachability 
configuration template. The setup program allows the VPN client software to be installed on the 

15 VPN client 140. When downloading the self-extracting executable, the configuration template 
is replaced with the VPN reachability information that is specific to the downloading user. 

According to another embodiment of the invention, the system allows the VPN client 140 
to download a self-extracting executable which, upon execution, only installs the VPN 
reachability information that is unique to the user. According to this embodiment, the VPN client 

20 software is already installed on the VPN client 140. In this scenario, the setup program allo^ 
the installation of the reachability information that is specific to the downloading user, on the 
VPN client 140. 

According to a third embodiment of the invention, the system allows the VPN client 140 
to automatically download the VPN reachability infomiation each time it connects to the policy 

25 enforcer 124, 126. Thus, VPN reachability information is k^t up-to-date for each VPN client 
140, Once a VPN session is established, the connection between the VPNt^lient 140 and the 
policy enforcer is assumed to already be secxire. The VPN client preferably makes a common 
gateway interface (COI) queiy to a web server running on the policy eafoveex, and downloads the 
current VPN reachability information fi-om the coiresponding LDAP database. 

30 FIG. 1 6 is a block diagram of components in a self-extracting executable 290 according 

to one embodiment of the invention. The self-extracting executable 290 may be created using 
commercially available tools such as the INSTALLSHIELD EXEBUILDER of InstallShiled 
Software Corporation of Schaumburg, Illinois. 

The self-extracting executable 290 preferably includes an executable setup file 292 for 

3 5 installing the VPN client software and/or the VPN configuration information. The setup file 292 
preferably forms a static portion 298 of the self-extracting executable since this information does 
not change based on the downloading VPN client. The self-extracting executable 290 further 
includes VPN configuration file templates for the VPN reachability information 294 and the VPN 

-19- 



SUBSTITUTE SHEET (RULE 26) 



iSDOClOE <WO. 



.007e004A3.IA> 



wo 00/078004 PCT/USOO/16246 

1 client's preshared key infonnation 296. The VPN Feachability inf<Hm£don 294 and the VPN 
client's preshared key 296 preferably form a dynamic portion 299 of the ^If-^xtracting 
executable 290 since this infonnation changes based on the downloading VPN client The self- 
extracting executable 290 is then saved as a template file in the policy •o^cicers 124, 126 and is 

5 ready to the downloaded by ihe remote users. 

FIG. 1 7 is a functional block dia^fam for downloading the self-extracting executable 290 
of FIG. 16 according to one embodiment of the invention. In step 320, a new VPN client 140 
first establishes a secure conmiimication session with the policy enforcer 124, 126 to download 
the self-extracting executable 290. Preferably, this is accomplished via an HTTPS protocol 

10 session on the VPN client's web browser or the like. In steps 322 and 324, fiie policy enforcer 
engages the VPN client in an authentication procedure where the policy enforcer requests, and 
the VPN client provides, his or her user name and password. In step 326, the policy enforcer 
compares the provided infonnation with entries in its VPN client database 328. If the 
infonnation is conect, the policy enforcer finds appropriate preshared keys for the user, and in 

15 step 330, also determines the VPN reachability infonnation of the client fi-om a VPN 
configuration database 332. The VPN client database 328 and VPN configuration database 332 
may reside as part ofasingleLDAPdatabase312,314managed by the poUcyCTforcer 124, 126, 
or may constitute separate LDAP databases. 

In step 334, the policy enforcer replaces the dynamic portion 299 of the self-extracting 

20 executable 290 with the VPN reachabflity information and preshared key that is xmique to the 
VPN client. The newly generated self-extracting executable is then downloaded to the VPN 
client 140 in step 336. When the executable is run, it either installs the VPN client software 
and/or the VPN reachability information. 

Similar techniques may also be used for downloading a new and updated copy of the VPN 

25 configuration information to the VPN client each time the client connects to the policy enforcer 
and negotiates a session key. In addition, the user may obtain the latest configuration of ^ VPN 
network by expressly requesting the policy enforcer for such information. Thus, the VPN client 
need not be reinstalled and reconfigured each time updates are made to the VPN reachability 
information. 

30 

VI. INTEG ATED POLICY ENFORCER 

According to one embodiment of the invention, the functionalities of the policy enforcer 
124, 126 for policy enforcement are partitioned for effective hardware implementation. 
However, it should be apparent to one skilled in the art that some or all of the functionalities may 
be implemented in software, hardware, or various combinations thereof. 

FIG. 18 is a schematic block diagram of the policy enforcer 124, 126 illustrating the 
partitioning of the various functionalities according to one embodiment of the invention. The 
policy enforcer includes an Internet protocol security (IPSec) engine 502 for performing security 
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and authenticationiunctioiis in implementing, for instance, virtual private networks. A stream 
table 506 ^sembles the packets passing through the policy enforcer ijrto streams. A protocol 
classification engine 508 decodes the protocols used in forwarding the packets. A policy -engine 
510 enforces policies for the packets based on the policy -settings stored in the policy database 
132, 134. A packet forwarding module 504 receives packets fi-om the public Internet via the 
router 110 and buffers, forwards, or. drops the packets based on flie policies being enforced. A 
bandwidth management module 514 provides bandwidth shaping services to the padsets being 
forwarded based on the bandwidth settings stored in the policy database 132, 134. 

In practice, an incoming packet is matched against the-stream table 506 for dete rmining 
if a matching entry already exists in the table. If not, a new entiy is added. The stream table 
preferably includes enough portions of the packet to imiquely identify a stream. For example, 
in enforcing policies on IP layer three through layer four trafRc, the stream table may store a 
source IP, destination IP, source port, destination port, and protocol number pf the incoming, 
packet 

The protocol classification engine 508 takes the new stream and obtains a detailed 
protocol decode for the stream. The policy engine 5 10 is then queried for the policy rales to be 
applied to the stream. Based on the policy rules retumed by the policy engine 510, the packet 
forwarding module 504, IPSec ei^ine 502, and/or the bandwidth management module "514 
process the streams accordingly. The processing may be recursive until the packets in the stceam 
have had all the actions specified by the policy rule set applied to them. 

The policy enforcer also includes a statistics module 5 12 for collectiiig statistics on the 
packets forwarded through the local network as well as other status and resource usage 
information, and provides the same in logs and archives for sending to the policy server 122. 
According to one embodiment of the invention, the statistics module 512 keeps running byte 
counts of the packets passing through the network 102, 104. These byte t:oimts may be 
automatically sorted by classes, such as classes based on certain resourGes^e.g. users, hosts, 
services), as well as by bytes that are blocked by policies and exceptions, such as firewall 
policies. In this regard, the statistics module. 512 maintains in a cache a state table including a 
list of resources involved for each connection allowed through the firewall. For eveiy packet 
flowing througih the connection, the statistics module increments the packet and byte count for 
each of the resources in the list The statistics module 512 then forwards the organ^ed 
information to the policy server 122 which enters tiie information directly into tables organized 
by classes and aged out periodically. 

FIG. 19 is a more detailed schematic block diagram of the policy engine 510 according 
to one embodiment of the invention. The policy engine 510 includes a policy request table 602 
that acts as a queue for all the policy decision requests. In this regard, the portion of the packet 
matching the information stored in the stream table 506 is presented to the policy engine 5 10 in 
the form of a policy request. The policy request is then queued in the policy request table 602. 
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1 A resouToe engine 604 maintains an \q>-to-date mair Jig ot resource tgroiip nanoes to 

member mappings. A policy rules database buffer 608 sti a cuirent policy rule set to be 
applied by the policy engine 5 10. The policy rules stored m buikx 1608 are preferably in the 
original group-based rule specification format. Thus, the b: 608 stores a rule CTeated for a 

5 group in its group-based form instead of instantiating a rule loi each member of tfae^roup. 

A decision engine 606 includes logic to serve the incoming policy decision requests in 
the policy request table 602 by matchmg it against the policy rule set in the policy rules database 
buffer 608 based on the actual membership information obtained fixjm the resource engine 604. 
The relevant group-based rule matching the traffic iis then identified and decision bits in the 

1 0 stream table set for enforcing the corresponding actions. The decision bits thus constitute the set 
of actions to be perfonned on the packets of the stream. All packets matching the streams are 
then processed based on these decision bits. The decision engine may also specify an access 
control list (ACL) including a set of rules that allow/deny tralfic, a DifiServ standard for 
providing a quality of service level to the trafBc, and/or VPN unpiementation information. 

1 5 FIG. 20 is a more detailed schematic block diagram of the protocol classification engine 

508 according to one embodiment of the invention. As illustrated in FIG. 20, the protocol 
classification engine 508 includes a stream data assembly 702, a sliding stream data window 704, 
an ASN.l block 706, a protocol classification state machine 708, and a protocol definition 
signature database710. The streain data assembly 702 extracts and re-assembles the data portion 

20 of an input packet stream and stores it in the sliding stream data window 704. Preferably, the 
sliding stream data window follows first-in-first-out protocols. The ASN.l decoder finlher 
decodes the data stream, if needed, per conventional ASN.l encoding/decoding standards. The 
protocol classification state machine 708 then matches the fully re-asi^embled and decoded data 
against the protocol definition signature database 710. This database 710 preferably holds a 

25 mapping of protocol names to data patterns to be found in the data stream. The matched protocol 
is then returned to the stream table 506. 

Thus, the protocol classification engme 508 provides extensive layer three through layer 
seven protocol decode and packet classification, includii^ complete identification of dynamic 
streams using a dynamically updated signature database compiled from scripted protocol 

30 definitions. As new protocols are defined m the fijture and/or users create their own custom 
applications with custom protocols, a need may arise to add recognition of these protocols to the 
protocol classification engme. The described protocol classification engine architecture allows 
such additions by simply adding a new scripted definition of the new protocol to the protocol 
classification engine without having to change the design each time a new protocol is added. 

35 This allows for custom protocol support and future protocol extensibilit3 

FIG. 21 is a more detailed schematic block diagram of the BPSec engine 502 according 
to one embodiment of the invention. As illustrated m FIG. 21, the IPSec engine 502 mcludes.a 
Pseudo-Random Number Generator (PRNG) fimction 802 for generating random numbers used 
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1 for crypto^aphic key ^enwation according to well known methods. A Di£5e Hellman 804 and 

RSA 812 blocks implement the corresponding asymmetric public key 
encryption/decryption/signature algorithms which are also well known in the art. An IKE bloc* 
806 commimicates with an IPSec S A table 808 for implementing standard IS AKMP/Oakley(IKE) 
5 key exchange protocols. A cryptographic transforms block 814 implements standard symmetric 
encryption/decryption algorithms. An IPSec Encapsulation/Decapsulation block 810 performs 
standard encapsulation/decapsulation functions. Accordingly, the IPSec ^xigine 302 provides 
mature, standards-based IKE/IPSec implementation with public key certificate support and 
necessary encryption/decryption functionality for packets passing tiirough the private local 
10 networks 102, 104. 

Vn. NETWORK POLICY LOGS AND STATISTICS AGGREGATION 

Referring again to FIG. 3, the log collecting and archiving module 304 collects 
information about the status and usage of resources from the policy enforcers 124, 126 as well 
as from the management module 302, and stores them in the archive database 318. The policy 
server reports module 316 then uses the collected logs and archives to generate reports in an 
organized report format. 

According to one embodiment of the invention, each policy enforcer 124, 126 maintains 
a log file with information collected about the flow of traffic through the policy enforcer as weU 
as the status and usage of resources associated with the policy enforcer. All the log files follow 
a predefined common log format, preferably designed to t^ate compact logs. 

FIG. 22 is a schematic layout diagram of such a log format according to one embodiment 
of the invention. Each log entry includes a timestamp 820 in the format yyyymmddhhnunss, 
indicative of the year, month, date, hours, minutes, and seconds in which the log entry was 
created. A service field 822 indicates the type of service rendered by the policy enforcer 124, 
126. Such services include VPN, FTP, Telnet, HTTP, packet filter, bandwidth, and the like. 
Each log entry further includes a source IP address and port 824 indicating the source fi-om where 
a packet was received, as well as a destination IP addr^s and port 826 indicating the destination 
to which the packet was forwarded. 

A user ID field 828 identifies the user transmitting the packet. The user ID may be 
mapped to an entry in the LDAP database 1 30, 1 32, or 1 34 for obtaining additional details about 
the vsGi. 

A status field 830 indicates the status of an operation and may include a result code, error 
code, and the like. For example, for a packet filter so-vice, the status field may include a result 
code "p" if the packet was passed or code "b*' if the packet was blocked. 

An operation field 832 indicates codes for a type of operation conducted by the service. 
For instance, operations for a VPN service may include sending packets and receiving packets. 



20 
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1 Operations for an FTP service may include GET and PUT opa^tions. Opeiati(»is€or an HTTP 
service may include GET and POST operations. 

In addition to the above, each log en^ includes an in-bytes field 832 indicative of the 
number of bytes the policy enforcer received as a result of the activity, and an oiit-bjrtes Seld 834 
5 indicative of the number of bytes transferred from the policy enforcer. Furd^miore, a duration 
field 836 indicates the duration (e.g. in seconds) of the activity- 
Certain fields of a particular log entry may be left blank if not applicable to a particular 
service. For instance, for an FTP download. Where there is no outgoing trafiBc, the out-bytes 
field is left blank. Furthermore, additional fields may be added based on the type of service being 
10 logged. For instance, for an HTTP activity, the URL that is accessed is also logged in the log 
entry. The additional fields are preferably appended to the end of the standard log format. 

A person skilled in the art should recognize that ad/iitions, deletions, and other types of 
modifications may be made to the log format without departing from the spirit and the scope of 
the invention as long as the log format common to all the policy enforcers and is aimed in 
IS creating compact logs. 

The log files created by the policy enforcers 124, 126 are transferred to the policy server 
122 based on archive options set by the policy server. In this regard, the network administrator 
specifies a threshold size for the logs created by the policy enforcers i5X)n selection of the policy 
server archive option 752 of FIG. 9. When the log file exceeds the specified size, it is sent to the 
20 policy server 1 22. Preferably, the logs are transferred to the policy server 122 at least once a day 
even if the threshold size has not been exceeded. The logs may also be archived locally at the 
policy enforcer if so specified by the network administrator. 

Once the policy server 122 receives the logs, it is stored in the archive database 318 
preferably taking the form of an SQL database. The policy server reports module 316 queries this 
25 database to generate reports for each policy enforcer 124, 126. In addition, the logs may be 
exported in a format that may be interpreted by commercially available products such as 
WEBTRENDS, manufactured by WebTrends Corporation of Portland, QregoiL 

The reports created by the reports module 316 include summary usage reports for the 
various resoru-ces including policy enforcers, users, services, hosts, and VPNs. For instance, the 
30 reports may include VPN siunmaiy reports, bandwidth summary reports, packet filtOTrq>orts, and 
the like, for each policy enforcer. 

The reports preferably show usage of each of the resources over a period time. The start 
and the end date for the report may be specified by the user. The user may further drill down on 
the time dimension and on the resoxuce dimension for viewing specific times and specific 
35 resources. For instance, in creating the packet filter reports, the user may indicate a start and end 
time, source IP address, source port, destination IP address, and destination port. All packets 
meeting these criteria are then fetched fi-om the archive database 318 and shown in a packet 
report. 
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1 

Vin. IVIETHOD FOR SELECTIVE LDAP DATABASE SYNCHRCWIZATION 

According to one embodiment of the invention, the databases 1 30, 1 32, 1 34 in the imified 
policy management system of FIG. 1 are LDAP databases storing policy management 

5 information including policies for firewall, VPNs, bandwidth, administration, user records, 
. network records, services, and the like. As described above, the LDAP directory service model 
is based on entries where each entry' is a collection of attributes. Entries are arranged in a tree 
structure that follows a geographical and organizational distribution. Entries are named 
according to their position in the hierarchy by a distinguished name (DN). 

ID The policy server 122 preferably stores the polkry management information €or all the 

policy enforcers in the policy server database 130. lliis information is organized in the databases 
1 30 as one or more DNs with corresponding attributes. Appropriate portions of the policy server 
database arc then copied to the policy enforcer databases 132, 134. 

FIG. 23 is a block diagram of an LDAP tree structure including an LDAP root 265 and 

15 a plurality of branches 264, 266, 268, 270. According to one example, the policy server 122 
maintains in the policy server database 130 branches 264 and 266 with policy management 
information for all the policy enforcers 124, 126. Each of the policy enforcers 124, 126 also 
maintain portions of the branches 264 and/or 266 in their respective policy enforcer databases 
1 32, 1 34 as sub-trees of the policy server database 1 30. The portions of the branches maintained 

20 by each policy enforcer 124, 126 preferably relates to the configuration information for that 
policy enforcer as well as some additional information about the other policy enforcers. This 
additional information is used to communicate with the other policy -enforcers. 

The policy server 122 may further maintain branch 268 storing information used only by 
the applications ninning on the server and not shared with any of the policy enforcers 124, 126. 

25 Likewise, policy enforcers 1 24, 1 26 may maintain a portion of branch 268<X)ntaining information 
used only by the applications on each of the policy enforcers and not shared elsewhere. 
Typically, the data stored in branch 268 is d)aiamically generated and used by the applications 
running on the corresponding server or agent. 

Branch 270 is preferably only included in the LDAP tree for the policy server databiase 

30 130 and stores logged policy mans^ement changes that may be propagated to the policy enforcers 
124, 126. Such changes may include, for example, addition, deletion, or modifications of a user 
on a device, VPN cloud, bandwidth policy, or firewall policy made by the network administrator 
via the various graphical user interfaces described above. Such changes result in the updatii?^ 
of the policy database 130 where the corresponding DN of the LDAP tree is added, deleted, or 

35 modified. The policy server 122 further creates a log of the changes and stores them in branch 
270 for later distribution to the policy enforcers 124, 126. 

FIG. 24 is a more detailed block diagram of branch 270 of the LDAP tree of FIG. 23. The 
LDAP root 265 includes an ApplyLog 270a entry which in turn includes a user log entry 270b 
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1 and a device log entry 270c. The user log entries include specific administeitor log entries 

identified by specific DNs 270d for Feflecting the changes made by tl^ particular miministrators. 

The device log entry 270c includes ^q)ecific device log entries identified by specific DNs 270e 

reflecting the changes that ar^ to be distributed to the particiilar policy enforces 124, 126. 
5 Preferably, the changes made by the administrators are propagated to the policy enforcers 124, 

126 upon actuation of an apply button such as the apply button 417 illustrated in FIG. 6. 

FIG. 25 is a flow diagram for logging and propagatirig LDAP changes to the policy 

enforcers according to one embodiment of the invention. In step 420, a particular network 

administrator makes a policy setting change. According to one example, the administrator is 
1 0 administrator "adm" working in the domain "domainl and the change is the addition of a new 

user on a device. 

In step 422, the change made the administrator is reflected in the policy server database 
1 30. In this regard, branches 264 and 266 of the LDAP tree are modified accordingly to reflect 
the change in the policy setting. Additionally, in step 424, the policy servCT 122 creates a log of 

1 5 the changes for the administrator for later processing and sending to the appropriate policy agent. 
In step 426, the policy server 1 22 updates the administrator' s log DN 270d to reflect the change. 
In the above example and as illustrated in FIG. 24, if the log created is named "A_L1 the policy 
server 122 updates the DN 270d for "adm" at "domainl " to create an attribute "apply'' 270f that 
has the value "A_L1" 270g. Other changes made by the administrator are reflected in separate 

20 logs (e g. "A_L2," "A_L3") and appended to the existing value of the apply attribute in the 
administrator's log DN 270d. 

In step 428, the policy server 122 checks whether the changes made by the adminisdrator 
are to be propagated to the appropriate policy enforcers 124, 126. As discussed above, the 
changes are preferably propagated upon actuation of an apply button firom the administrator's 

25 graphical user interface. 

If the apply button has been actuated, the policy server creates, in step 430, a log for each 
policy enforcer to whom the change is to be transmitted. In this regard, the policy server 122 
collects all the changes made by the administrator as reflected in the values 270g, 270h of the 
apply attribute 270f of the administrator's log DN 270d. These changes are processed for each 

30 policy enforcer belonging to the administrator's domain. Such processing preferably involves 
picking the relevant changes and suitably modifying the DNs for the policy ^oicer's LDAP. 
Such suitable modifications may be necessary, for instance, due to the differences in the tree 
stractures in the policy server database 130 and the poUcy enforcer databases 132, 134. For 
instance, a change in the administrator's log may contain a DN that specifies the domain name 

35 of the policy enforcer. In applying this change to the policy enforcer, the domain name would 
not be specified in the DN since the policy enforcer's tree structure does not include a domain 
name. 
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1 The -changes ^itably modified for each policy enToFcer's LDAP are then stored in a 

device log. Each policy enforcer's log DN 270e is then modified to reflect the change to the 
transDfiitted to the particular policy enforcer. In the above example and as illustrated in FIG. 24, 
if the device log created is named "PE_L1," the poUcy server 122 updates the DN 270e for the 

5 particular policy enforcer "PEl" at "domainl" to cieate an attribute "apply" 2701 that has flie 
value "PE_Lr'270j. 

In step 432, the apply attribute 270f for the administrator's log DN 270d is then deleted 
from the LDAP tree. In step 434, the changes collected for each policy enforcer, as reflected in 
the values 270j, 270k of the apply attribute 270i of the policy enforcser's log DN 270e, are 

10 transmitted to the policy enforcer for updating its database 1 32, 1 34. The changes are sent to the 
policy enforcers preferably over the H i IPS channel. 

In step 436, the policy server 122 checks whether the updates have been successfiil. In 
this regard, the policy server 122 waits to receive an acknowledgment from the policy enforcer 
that the updates have been successfully completed. Upon a positive response from the policy 

15 enforcer, the policy server 122 deletes the apply attribute 270e for the policy enforcer's log DN 
270e. Othenvise, if the update was not successful (e.g. because the policy enforcer was down), 
the apply log is re-sent the next time another apply frmction is invoked. Alternatively, the failed 
policy enforcer transmits a request to the policy server 122 of the log of non-applied changes 
when it rejoins the network (e.g. by rebooting). 



20 



IX. STATE TRANSITION PROTOCOL FOR HIGH AVAILABILITY UNITS 



According to one embodiment of the invention, the policy server 122, policy enforcers 
124, 126, as weU as other network devices may be configured for high availability by maintaining 
a backup imit in addition to a primary unit. 

FIG. 26 is a schematic block diagram of a high availability system including a primary 
unit 902 and a backup unit 904. The two vinits 902, 904 commxmicate with each other by 
exchanging heartbeats over parallel ports 906a, 906b and a cable 908. Such parallel ports 906a, 
906b and cable 908 are conventional components that are commonly available in the art. 

The primary unit 902 and the backup unit 904 are each similarly connected to other 
^® components 910, 912, 914 via ports 920a, 920b, 922a, 922b, 924a, 924b, respectively. These 
components 910, 912, 914 may be hubs, switches, connectors, or the like. Because the primary 
unit 902 and backup unit 904 provide similar services and functions and may be u^ 
interchangeably, each unit is preferably connected to the same components 910, 912, 914. 

The parallel port cable 908 is preferably aconventional laplink cable designed to connect 
two parallel ports and allow communications between them. The primary unit 902 and the 
backup xmit 904 preferably communicate with each other via TCP packets over the high- 
availability ports 906a, 906b. A point-to-point coimection preferably exists between the primary 
unit 902 and the backup unit 904 over the high-availability ports 906a, 906b. 
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1 The primary unit 902 is jweferably ^^sponsibk for choking the status of its^ietwork ports 

for problems or failures. For example, if the primary unit 902 detects that one of its network 
ports is inoperable, e.g. port 922a, the jaimary unit 902 then^hecks whether tiie oorresponding 
port 922b in the backup unit 904 is operational. Upon determining that the coipesponding port: 
S 922b in the backup unit 904 is operational, the primaiy unit 902 -sends a request to the backup 
imit 904 to take over the system functions as the active unit The primary unit 902 tiien 
relinquishes its role as the active unit and shuts itself down, allowii^ the backup unit 904 to take 
on the responsibilities of the primaiy unit 902. When the primaiy unit 902 restarts operation, the 
backup unit 904 receives a request from the primary unit 902 to relinquish its role as the active 
10 imit. 

When the primary xinit 902 is active and does not detect any defects in its ports, it 
continuously listens on the high-availability port 906a to keep track of the status of the backup 
unit 904. The primary unit 902 continues to listen on the high-availability port 906a for signals 
coming from the backup unit 904. When the backup unit 904 is up and running, it connects to 

15 the primary unit 902. Once the connection is made, the backup unit 904 begins sending 
heartbeats to the primary unit 902. The backup unit 904 continuously sends heartbeats to the 
primary unit 902 in predetermined intervals. According to one embodiment of the invention, the 
backup unit 904 sends a "Keep Ahve" packet including a KEEP^ALFVE command to the 
primary unit 902 every one second. 

20 The primary unit 902 responds to the "Keep Alive" packet by changing the conomand field 

of the packet to a KEEP_ALIVE_RESP command and re-transmitting the packet to the sender. 
If the backup vmit 904 does not receive a response back fi-om the primary unit 902 for a 
predetermined period of time (e.g. one second) for one "Keep Alive" packet, the backup unit 904 
begins preparing to take over the active role. Preferably, the predetermined period should not be 

25 greater less than two consecutive "Keep Alive" packets. 

Upon taking the role of the active unit, the backup unit 904 attempts to reestablish a 
connection with the primaiy unit 902 at regular intervals to determine whether the problem or 
failure in the primary unit has been cured. If the problem or failure has been cured, tite backup 
unit 904 relinquishes its control to the primary unit 902 after setting the TP addresses of all the 

30 network interface cards to the assigned value. 

In situations where the backup unit 904 takes over the active role fi*om the primary unit 
902, an alert/alann is sent to the network administrator indicating such a change. In addition, if 
the primary unit 902 does not receive heartbeats firom the backup unit 904, an alert/alann is sent 
to the administrator indicating that the backup imit has failed. 

35 A situation may arise when both the primaiy imit 902 and the backup unit 904 are fully 

functional, and the backup xmit 904 desires to take over the active role. In thisx^ase, the backup 
unit 904 transmits a shut-down command to the primary unit 902 which then pelinquishes control. 
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1 The backup iinit V04 continues its role as the active unit the primaiy unit 902 transmits a 
request to the backup unit 904 to relinquish its active role. 

Accordiiig to one embodiment of the invention, the initial status determination protocol 
of each high availability unit as a primary, backup, or stand-alone unit relies on a-self-discovery 

5 process. FIG. 27 is a flow diagram of an exemplary status discovery process according to one 
embodiment of tbe invention. In step 930, a first high availability unit<umt X) that has not yet 
definitively discovered its status as a primary or a backiq) unit boots up, and in step 932 assumes 
the role of a backup unit In step 934, unit X searches the network for a primary unit and 
inqxiires, in step 936, whether a primary unit has been detected. If the answer is YES, vmit X tries 

1 0 to connect to the primaiy unit. If it is successful, unit X initializes as the backiq) unit in step 938. 
If, on the other hand, unit X does not detect tiie primary unit, unit X assumes the role of the 
primary unit in step 940. 

In step 942, unit X searches the network for a backup imit. If the badcup imit is detected, 
as inquired in step 944, unit X connects to the backup unit and initializes as the primary unit in 

15 step 946. If, on the other hand, unit X does not detect any other imits in the network within a 
predetermined time, unit X initialises as a stand-alone imit in step 948, 

Once the primary and secondary units have been initialized, configuration changes of the 
primary unit are also transferred to the backup unit in order to keep the two units synchronized. 
The configuration information is preferably stored in an LDAP database such as tiie central policy 

20 server database 130 or policy agent databases 124, 126. 

FIG. 28 is a flow diagram of a process for maintaining configuration information 
synchronized in the primary and backup xmits. In step 950, the primary unit boots up and in step 
952, detects the backup unit. In step 954, the backup unit receives configuration change 
information from the primary imit if it is functional. Otherwise, the configuration changes are 

25 entered directly into the backup unit by the network administrator. If the configuration change 
is to be received fi^om the primary miit, the primaiy unit notifies the backup xmit when 
configxiration changes occur in the primary unit The changes are then transferred and applied 
to the backup unit. The backup unit in turn transmits the status of the transfer and the apply back 
to the primary unit. 

30- In step 956, the primary unit is checked to determine whether it is functional. If it is, the 

primaiy unit is likewise updated with the configuration change. Otherwise, if the primary imit 
is not functional, the backup unit takes on the active role and becomes the active imit in step 958. 
The primary unit may become non-functional and thus, inactive, due failures in the CPU board, 
the network interface card, or power supply. 

35 In step 960, the backup unit tags the changes to transfer them to the primary once the 

primary becomes functional. Once the primary unit becomes functional, the primary unit is 
updated with the tagged changes maintained by the backup unit as is reflected in step 962. 
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1 According to one embodiment oT the invention, -software updates on the primary and 

backup units are also synchronized so as to update the primaiy and backup units -serially in a 
single cycle without the need for multiple update cycles. Thus, the network administrator need 
not duplicate the eflforts of updating the backup unit with the same information as the primary 
5 imit 

FIG. 29 is an exemplary flow diagram of updating the primary and backup units when 
they are both functional. In step 970, an update, such as a software tqpdate not stored in the 
LDAP databases, is sent/transmitted to the primary unit fiom a management station accessible 
by the network administrator. The primary unit then iq)dates itself in step 972. In step 974, tihe 

10 piimary uiiit automatically sends/traiismits the update iriformation to the ^ In step 

976, the backup vmit updates itself with the update information received from the primary unit 
FIG. 3 0 is an exemplary flow diagram of updating the primary and backup imits when the 
primary unit is not functional. In step 978, the primary unit becomes nonfunctional, and in step 
980, the network administrator sends/transmits an upgrade directly to the backup xmit instead of 

15 the primary imit. In step 982, the backup unit updates itself with the information received from 
the management station and waits for the primary xmit to become functional. Once the primary 
unit becomes functional, the update is automatically sent/transmitted to the primaiy unit for 
upgrading in step 986. The primary unit then iq)dates itsdf in step 988, 

Although the present invention has been described in detail witihreference to the preferred 

20 embodiments thereof, those skilled in the art will appreciate that various substitutions and 
modifications can be made to the examples described herein while remainioe within the spirit 
and scope of the invention as defined in the appended claims. 

For example, the unified policy management system of FIG. 1 should be viewed as 
illustrative rather than limiting. It should be apparent to those skilled in the art who are 

25 enlightened by the present invention that many alternative configurations are possible. For 
example, there may be additional networks with policy enforcers or no additional networks at all. 
Likewise, policy enforcers may not necessarily access the policy server tiirough the Intemet, but 
may be connected via other means such as a WAN, MAN, etc. In short, the number and tjrpe of 
users and resources within and without the organization can vary greatly virile staying within the 

30 scope of the invention. 



35 
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1 CLAIMS: 

1. A system for managing policy services in an orgamzation, the organization 
including a &st network having a first set of resoiiroes and a second network remote from the 
first network having a second set of resources, the system comprising: 
5 a first edge device associated with the first network, the first edge device configured to manage 
policies for the first network and the first set of resources in accordance with first policy settings 
stored in a first database; ^ 

a second edge device associated with the second network, the second edge device configured to 
manage policies for the second network and the second set of resources in accordance with 
10 second policy settings stored in a second database; and 

a central policy server in conmiunication with the first and second edge devices, the central 
policy server configured to define the first and second policy settings and manage the first and 
second edge devices from a single location. 

15 2. The system of claim 1 , wherein the policies are firewall policies. 

3. The system of claim 1, wherein the policies are virtual private network policies. 

4. The system of claim 1 , wherein the central policy server includes acentral database 
20 for storing configuration information of the first and second edge devices. 

5. The system of claim 4, wherein the configuration information includes the first and 
second policy settings. 

25 6. The system of claim 4, wherein the central database stores a log of changes in the 

configination information for the first and second edge devices. 

1, The system of claim 6, wherein the policy server transmits the changes in the 
configuration information to the first and second edge devices for respectively updating the first 
30 and second databases. 

8. The system of claim 7, wherein the policy server deletes the log of changes upon 
a successfiil update of the first and second databases. 

35 9. The system of claim 4, wherein the central database and the first and second 

databases are organized according to a hierarchical object oriented structure. 
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1 0. The system of claim 9, v^rein the hier^cfaical object oriented-stoKture includes 
a pliirality of resource objects and policy objects for defining the first and^second policy settings. 

1 1 . The system of claim 10, wherein the resource objects are selected from ar^x)up 
consisting of devices, users, hosts, services, and time. 

12. The system of claim 10, wherein the central database and the first and second 
databases are Lightweight Directory Access Protocol (LDAP) databases storing each resource 
object and policy object as an LDAP entry. 



13. The system of claim 1, wherein the central policy server includes a set of user 
application modules for allowing a user to define the first and second policy settings and manage 
the first and second edge devices fi-om the single location, the first and second policy settings 
being associated with a plurality of resource objects including devices, users, hosts, services, and 

15 time. 

14. The system of claim 13, wherein the set of user application modules includes a 
centralized managemoit sub-module for allowing installation of the first andsecond edge devices 
from the single location. 

20 15. The system of claim 1 4, wherein the centralized management sub-module allows 

registration of the first and second devices with the central policy server. 

16. The system of claim 13, wherein the set of user ai^lication modules inc; ies a 
policy management sub-module for managing and vievsdng the resource objects fit>m the ngle 

25 location. 

17. The system of claim 1, wherein the central policy server includes a set of user 
application modules for allowing a user to monitor health and status of the first and second edge 
devices fi-om the single location. 

30 

1 8. The system of claim 1 , wherein the central policy server includes: 

a log collecting and archiving module for periodically receiving health and status 
information fi-om each of the edge devices; 

an archive database coupled to the log collecting and archiving module for storing the 
35 health and status information; and 

a reports module coupled to the archive database for creating reports based on the health 
and status information. 
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1 9. The system of claim 1 8, wherein^ch edge device-collects and transmits health and 
status information in a ppedefined common log format 

20. The system of claim 1 8, wherein the health and status information includes network 
flow information. 

21. The system of claim '18, wherein the health and status information includes 
statistics on use of each edge device's set of resources. 

22. The system of claim 1 , wherein each edge device includes a plurality of modules 
for integrating management of the policies for each of the networks into thC'edge device. 

23. The system of claim 22, wherein the plurality of modules include: 

a classification engine for deteraiining a protocol associated with an incoming packet; 
a policy engine for making a forwarding decision for the packet based on policy settings 
associated with the packet; and 

a packet forwarding module for forwarding the packet based on the policy ^settings. 

24. The system of claim 23 further including a security engine for autibenticating a user 
transmitting the packet. 

25. The system of claim 23 further including a statistics module for collecting statistics 
on packets flowing through the edge device. 

26. The system of claim 1 , wherein each network is a private network and each edge 
device is configiu-ed to create a table with information of member networks reachable through 
the edge device. 

27. The system of claim 26, wherein the first and second edge devices enable secure 
communication between the first and second private networks, and the first edge device shares 
the first table with the second edge device and the second edge device sharing the second table 
with the first edge device. 

28. The system of claim 26, wherein the first edge device includes logic for: 
receiving a new roxrte infomation; 

storing the new route infomiation in the first database; and 

transmitting a portion of the new route information to the second edge device. 
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29. The system x)f claim 26, wherein the -communication is managed accoiding to a 
security policy associated with the member networks. 



30. The system of daim 29, wherein the security policy is defined for a security policy 
5 group providing a hierarchical organization of thegroup, the group including member networks, 

users allowed to access the member networks, and a rule controllii^ access to the member 
networks. 

3 1 . The system of claim 30, wherein each member network has full connectivity with 
10 all other member networks and the security policy defined for the security policy ^oup is 

automatically configured for each connection. 

32- The system of claim 30, wherein the security policy provides encryption of traffic 
among the member networks and the rule is a firewall rule providing access control of the 
1 5 encrypted traffic among the member networks. 

33. The system of claim 30 further including remote user terminals for accusing the 
member networks form a remote location, each remote user terminal including a processor, the 
processor being operable to execute program instructions, the program instructions including: 

20 establishing conmiunication with the edge device; 

transmitting authentication information to the edge device; and 

receiving the table with the information of the member networks fix>m the edge device. 

34. The system of claim 33, wherein the program instructions further include 
25 automatically receiving updates of the table firom the edge device. 

35. The system of claim 1, wherein the central policy server and the first and second 
edge devices include first class units and second class units, each second class unit providing 
backup for a corresponding first class unit upon failure of the first class unit 

30 

36. The system of claim 35, wherein each of the second class units is initially in an 
inactive state, each of the second class units including logic for: 

detecting a failure of its corresponding first class imit; and 

transitioning fiom the inactive state to an active state upon detection of the failure. 

35 

37. The system of claim 35, wherein each of the second class xmits iircludes logic for: 
assuming a role of the second class imit; 

searching for the corresponding first class unit; and 
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1 initializing as tiie second class vmt if the corr-espondkig first class unit is detected. 

38. The system of claim 37, wherein each of the second class vmits further includes 
logic for: 

5 assiuning a role of the first class unit if the first class unit is not detected; 

searching for a corresponding second class unit; and 

initializing as the first class unit if the corresponding second class unit is detected. 

39. The system of claim 38, wherein «ach of the second -class units fimher includes 
10 logic for initializing as a third class unit if the corresponding second class unit is not detected. 

40. The system of claim 35 further comprising: 

means for transitioning each of the first class units to an active state; 
means for receiving and storing first database configviration changes for each of the first 
rs class units; 

means for transferring the configuration changes to the corresponding second class units; 

and 

means for storing the configuration changes on the corresponding second class units. 

20 41. The system of claim 40 further comprismg: 

means for transitioning each of the first class units to an inactive state; 
means for receiving and storing second database configuration changes for the second 
class unit while the corresponding first class unit is in the inactive state; and 

means for transferring the second database configuration changes from the second class 

25 unit to the first class unit after the first class unit re-transitions to the active state. 

42. The system of claim 35 further comprising: 

means for transmitting update information to each of thie first class unite; 
means for updating each of the first class imits; 
30 means for transmitting the update information fiom each of the first class units to each 

of the second class units; and 

means for updating each of the second class units. 

43. A system for managing poUcy services in an organization, the organization 
35 including a first network having a first set of resom-ces and a second network remote from the 

first network having a second set of resources, the system comprising: 
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1 a Erst edge device associated with the first network, thefirst edge device cor£gured 

to manage policies for the Urst network and the first set of resovHX^ in accordance with first 

policy settings stored in a first database; 

a second edge device associated with the second network, the second edge device 
5 configured to manage policies for the second network and the second set of resources in 

accordance with second policy settings stored in a second database; and 

a central policy server defining the first and second policy settings and managing 

the first and second edge devices firom a single location, the central policy server being associated 

with a central database storing configuration information of the first and second edge devices, 
ID wherein the central database is organized according to a hierarchical object oriented structure. 

44. The system of claim 43, wherein the first and second databases are organized 
according to the hierarchical object oriented structure. 

15 45. The system of claim 43, wherein the configuration information includes the first 

and second policy settings. 

46. The system of claim 45, wherein the hierarchical object oriented stracture includes 
a plurality of resource objects and policy objects for defining the first and'second policy settings. 

20 

47. The system of claim 46, wherein the central database and the first and second 
databases are Lightweight Directory Access Protocol ^DAP) databases storing each resource 
object and policy object as an LDAP entry. 

25 48. The system of claim 46, wherein the resource objects are selected fi:om a-group 

consisting of devices, users, hosts, services, and time. 

49, The system of claim 48, wherein the devices include the first and second edge 
devices, each device being associated with a set of users and a particular host 



30 



35 



50. The system of claim 48, wherein the hosts include the first and second networks. 

51. The system of claim 46, wherein the policy objects are selected fi-om a group 
consisting of bandwidth, firewall, administration, and virtual private network grouping. 

52. The system of claim 5 1 , wherein the virtual private network groiq)ing includes a 
virtual private network associated with one or more sites, users, and rules. 
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1 53 . The system of claim 52, ^A^ierein each site includes one or more networks behind 

an edge device. 

54. The system of t:laim 52, wherein the rules are firewall rules providing access 
5 control over network traffic flowing through the virtual private network. 

55. A system for selective database synchronization comprising: 

a central database storing configuration information for a plurality of edge devices in an 
organization, each edge device being associated with a network in the organization and 
1 0 configured to manage policies for the network; 

a subordinate database storing a portion of the configuration information associated with 
a particular edge device; and 

a central policy server in communication with the central database and the subordinate 
database, the central policy server including logic for: 
1 5 making a change to the portion of the configuration infomiation associated with the 

particular edge device in the central database; 

creating a log of the changes; 

storing the log in the central database; and 

transferring the changes to the particular edge device for updating the subordinate 

20 database. 

56. The system of claim 55, wherein the log includes a user log for associating the 
change to a particular user making the change, the particular user being associated with the 
particular edge device. 



25 



35 



57. The system of claim 56, wherein the central policy server further includes logic for 
identifying the particular edge device based on the particular user making the change. 



5 8 . The system of claim 57, wherein the log includes a device log for storing the change 
30 for the particular edge device. 

59, The system of claim 55, wherein the central policy server further includes logic for: 

receiving a status of the transfer fi-om flie particular edge device; and 

deleting the log firom the central database if the status indicates a successftil transfer. 



60. The system of claim 55, wherein the central database and the subordinate database 
are Lightweight Directory Access Protocol (LDAP) databases storing configuration information 
as an LDAP entry identified by a distinguished name- 
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^1. The system of claim 55, wherein the configuration infoimation is policy 
management inibmiation. 



62. In a system including a^first edge device managing policies for a first network 
according to first policy settings and a second edge device managing polides for a second 
network according to second policy settings, the system further including a central policy server 
in commvmication with the first and second edge devices configured to define the first and-second 
policy settings and manage the first and second edge devices firom a single location, each edige 
device comprising: 

a classification engine for determining a protocol associated with an incoming packet; 
a policy engine for making a forwarding decision for the packet based on policy settings 
associated with the packet; and 

a packet forwarding module for forwarding the packet based on the policy settings. 

63 . The edge device of claim 62, wherein the classification engine fiirther includes a 
protocol database storing a mapping of protocols to data patterns found in a packet stream. 

64. The edge device of claim 62, wherein the policy engine fiulfaer includes a resource 
engine with a current mapping of resource group names to members in -each group. 

65. The edge device of claim 64, wherein the policy engine fiirther includes a policy 
rules buffer storing policy settings specified for a group associated with the packet 

66. The edge device ofclaim 64, wherein the poUcy engine further includes a decision 
engine for matching the packet with the policy settings in the policy rules biiffer based on 
membership information firom the resource engine. 

67. The edge device of claim 62 fijrther including a security engine for authenticating 
a user transmitting the packet 

68. The edge device ofclaim 62 fiirther including a statistics module for collecting 
statistics on packets flowing through the .edge device. 

69. The system ofclaim 68, wherein the statistics module maintains a byte count of the 
packets flowing through the edge device, wherein the b3^e count is organized according to 
resources associated with the packets. 

70. A computer network comprising: 
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a first edge tJevice cot5>Ied to a first private network, the first edge device configured to 

create a first table with information of member networks reachable through the first edge device, 

the first table being -stored in a first database; 

a second edge device coupled to a second private network, the second edge device 

configured to create a second table with information of member networks reachable through the 

second edge device, the second table being stored in a second database; 

wherein, the first and second edge devicesenable secure communication between the first 

and second private networks, and the first edge device shares the first table with the second edge 

device and the second edge device shares the second table with the first edge device. 



7 1 . The computer network of claim 70, v^erein the first edge device includes logic 



for: 



receiving a new route information; 

storing the new route information in the first database; and 
15 transmitting a portion of the new route information to the second edge device. 

72. The computer network of claim 71, wherein the pcHtion of the new route 
information is a route name. 

20 73. Thecomputernetworkofclaim71,whereinthesecondedgedeviceincludeslogic 

for 

receiving the portion of the new route information; 

accessing the first database based on the portion of the new route information; 
retrieving the new route information fi^om the first database; and 
25 storing the retrieved route information in the second database. 

74. The computer network of claim 70, wherein commtmication between the first and 
second networks is managed according to a security policy associated with the networks. 

30 75. The computer network of claim 74, wherein the security policy is defined for a 

security group providing a hierarchical organization of the group, the group including member 
networks, users allowed to access the member networks, and a rule controlling access to the 
member networks. 

35 76. The computer network of claim 75, wherein each member network has fiiU 

connectivity with all other member networks and the security policy defined for the secimty 
policy group is automatically configured for each connection. 
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1 77. The compirter network of claim 75, whepein the security policy fwovides 

encryption of traffic among the member networks and the rule is a&ewall rule providing access 
control of the encrypted traffic among the member networks. 

5 78. A computer network comprising: 

an edge device coupled to a private network, the edge device coi^gui^ed to create a table 
with information of member networks reachable through the edge device, the table being stored 
in a database; 

a remote user terminal in communication with the edge device, the remote user terminal 
1 0 including a processor, the processor being operable to execute program instructions, the program 
insmictions including: 

establishing communication with the edge device; 

transmitting authentication information to the edge device; and 

receiving the table with the inforaiation of the member networks from the edge 

15 device. 

79. The computer network of claim 78, wherein the program instructions further 
include automatically receiving updates of the table from the edge device. 

20 80. The computer network of claim 78, wherein the program instractions further 

include downloading a client software for installation and execution. 

81. The computer network of claim 80, wherein the client software allows 
commimication with the member networks reachable through the edge device. 

25 

82. The computer network of claim 80, wherein the client software allows the 
downloading of the table with the information of the member networks. 

83- The computer network of claim 80, wherein the client software includes a static 
30 portion and a dynanwc portion, the static portion including an executable setap file and the 
dynamic portion including a template for being rq>laced with information specific to the 
downloading remote user terminal. 

84. The compmer network of claim 80, wherein the dynamic portion is replaced with 
35 the table from the edge device with the information of the member networks. 
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1 85. A system for managing policy iservic« in an organization, the organization 

including a first network having a iirst set of resources and a second network remote from the 
jBrst network having a second set of resources, the ^stem comprising: 

a first edge device associated with the first network, the first edge devicexonfigured to 

'5 manage policies for the first network and the first set of resources in accordance with first policy 
settings stored in a first database; 

a second edge device associated with the second network, the second edge device 
configured to manage policies for the second network and the second set of resources in 
accordance with second policy settings stored in a second database; and 

10 a central policy server in communication with the first and second edge devices, tiie 

central policy server configured to defiine the first and second policy settings and monitor health 
and status of the first and second edge devices fi*om a single location. 

86. The system of claim 85, wherein the central policy server includes: 

15 a log collecting and archiving module for periodically receiving health and status 

information fi-om each of the edge devices; 

an archive database coupled to the log collecting and archiving module for storing the 
health and status information; and 

a reports module coupled to the archive database for creating reports based on the health 
20 and status information. 

87. The system of claim 86, wherein each edge device collects and transmits health 
and status information in a predefined common log format. 

25 88. The system of claim 86, wherein the health and status information includes 

network flow information of packets flowing through the edge device. 

89. The system of claim 88, wherein the each edge device maintains a bytexoiint of 
the packets flowing through the edge device, wherein the byte count is organized according to 

30 resources associated with the packets. 

90. The system of claim 86, wherein the health and status information includes 
statistics on use of each edge device's set of resources. 

35 91. The system of claim 90, wherein the reports indicate usage of the resources 

associated with a particxilar edge device over a period of time. 
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92. The system oft:laim 86, Avberein the centi^ policy se^^ 

for determining when each of the edge devices is to transfer the health and status information to 
the log collecting and archiving module. 

93. A high-availability system comprising: 

a first edge device managing policies of a first network; 

a second edge device managing policies of a second network; and 

a central policy server in commimication with the first and ^second edge devices, the 
central policy server managing the first and second edge devices firom a single location; 

wiierein, the central policy server and the first and second edge devices include first class 
units and second class units, each second class unit providiiig backup for a corresponding first 
class vant upon failure of the first class unit. 

94. The system of claim 93, wherein each of the second class units is initially in an 
inactive state, each of the second class imits including logic for: 

detecting a failure of a corresponding first class unit; and 

transitioning fi-om the inactive state to an active state upon detection of the feilure. 

95. The system of claim 93, wherein each of the second class units inclixies logic for: 
assuming a role of the second class xmit; 

searching for the corresponding first class unit; and 

initializing as the second class unit if the corresponding first class vmit is detected. 

96. The system of claim 95, wherein each of the second class units further includes 
logic for: 

assuming a role of the first class unit if the first class imit is not detected; 
searching for a corresponding second class imit; and 

initializing as the first class unit if the corresponding second class unit is detected. 

97. The system of claim 96, v^iierein each of the second class units further includes 
logic for initializing as a third class unit if the corresponding second class unit is not detected. 

98. The system of claim 93 further comprising: 

means for transitioning each of the first class imits to an active state; 
means for receiving and storing first database configuration changes for each-of the first 
class units; 

means for transferring the configuration changes to the corresponding second class imits; 

and 
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1 means for storing the<:onfiguration changes on the corresponding seoondK:lass units. 

99. The system of claim 98 further comprising: 
means for transitioning each of the first class xmits to an inactive state; 
5 means for receiving and storing second database configuration changes for the second 

class vmit while the corresponding first class imit is in the inactive state; and 

means for transferring the second database configuration changes from the second class 

unit to the first class unit after the first class unit re-transitions to the active state. 

10 1 00. The system of claim 93 further comprising: 

means for transmitting update information to each of the first class units; 
means for updating each of the first class units; 

means for transmitting the update information firom each of the first class units to each 
of the second class units; and 
15 means for updating each of the second class units. 

101. In a system including a first network having a first set of resources and a second 
network remote from the first network having a second set of resources, the first network being 
associated with a first edge device and a first database, and the second network being associated 

20 witii a second edge device and a second database, the system fiirtiber including a central policy 
server in communication with the first and second edge devices, a method for managing policy 
services in the system comprising: 

storing first policy settings in the first database; 
storing second policy settings in the second database; 
25 managing policies for the first network and the first set of resources from the first edge 

device in accordance with the first policy settings stored in the first database; 

managing policies for the second network and the second set of resources from the second 
edge device in accordance with the second policy settings stored in the second database; and 
defining the first and second policy settings and managing the first and second edge 
30 devices from the central policy server from a single location. 

1 02. The method of claim 101, wherein the policies are firewall policies. 

103. The method of claim 101, wherein the policies are virtual private network policies. 



35 



104. The method of claim 101, wherein the central policy server includes a central 
database and the method further comprises storing configuration information of the first and 
second edge devices in the central database. 

-43- 



SUBSTITUTE SHEET (RULE 56) 



JSOOCtO: <WO. 



.0078004A3_IA> 



wo 00/078004 



PCTAJS00/11S246 



1 

1 05. The method of claim 1 04, wherein tiie configuration ixifoimation includes the first 
and second policy settings. 

S 1 06. The method of claim 1 04 further comprising: 

making changes to the configuration information of the first and second edge devices; and 
storing a log of the changes in the central database. 

1 07. The method of claim 1 06 further comprising transmitting the log of the changes 
1 0 to the first and second edge devices for respectively updating the first and second databases. 

1 08. The method of claim 1 07 further comprising deleting the log of changes from the 
central database upon a successful update of the first and second databases. 

15 1 09. The method of claim 1 04, wherein the central database and the first and second 

databases are organized according to a hierarchical object oriented structure. 

110. The method of claim 109, wherein the hierarchical object oriented structure 
includes a plurality of resource objects and policy objects for defining the first and second policy 

20 settings. 

111. The method of claim 110, wherein the resource objects are selected from a group 
consisting of devices, users, hosts, services, and time. 

25 112. The method of claim 110, wherein the central database and the first and second 

databases are Lightweight Directory Access Protocol (LDAP) databases storing each resource 
object and policy object as an LDAP entiy. 

113. The method of claim 1 01 further comprising installing the first and second^ge 
30 devices from the central policy server. 

1 1 4, Hie method of claim 101 further comprising registering the fibrst and second edge 
devices with the central policy server. 

35 115. The method of claim 1 01 further comprising monitoring health and status of the 

first and second edge devices from the central policy servo:. 

116. The method of claim 1 01 further comprising: 
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periodically receiving health and status inform^on from each of the -edge devices; 
storing the health and^atus information in an archive databaise; and 
creating reports based on the health and status information. 

117. The method of claim 116, wherein each -edge device collects and transmits health 
and status information in a predefined common log format 

118. The metiiod of claim 116, wherein the health and status information includes 
network flow information. 

119. The method of claim 116, wherein the health and status information includes 
statistics on use of each edge device's set of resources. 



120. The method of claim 101, wherein each edge device includes a classification 
15 engine, a policy engine, and a packet forwarding engine for integrating management of the 

policies into the edge device, and the managing of the policies for each of the networks further 
includes: 

determining a protocol associated v^dth an incoming packet using the classification engine; 
making a forwarding decision for the packet based on policy settings associated with the 
20 packet using the policy engine; and 

forwarding the packet based on the policy settings using the packet forwarding module. 

121. The method of claim 120, wherein each edge device includes a security engine 
and the managing of the policies for each of the networks further includes authenticating a user 

25 transmitting the packet 

122. The method of claim 120, wherein each edge device includes a statistics module 
and the managing of the policies for each of the networks further includes collecting statistics on 
packets flowing through tiie edge device. 

30 

123- The method of claim 101, wherein each network is a private networic and each 
edge device is configured to create a table with information of member networks reachable 
through the edge device. 

35 124. The method of claim 123, wherein the first and second edge devices enable secure 

communication between the first and second private networks, and the method further comprises: 
sharing the first table with the second edge device; and 
sharing the second table with the first edge device. 
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125. The method of diaiin 123 further comprising: 
receiving a new route information; 

storing the new route information in the first database; and 
"5 transmitting a portion of the new route information to the second edge device. 

1 26. The method of claim 1 23, wherein the communication is mans^ed according to 
a security policy associated with the member networks. 

10 1 27. The method of claim 126, further comprising defining the security policy for a 

security policy group, the group providing a hierarchical organization of the group including 
member networks, users allowed to access the member networks, and a rule controlling access 
to the member networks. 

15 128. The method of claim 127, wherein each member network has fiill connectiAdty 

with all other member networks, and the method further comprises automatically configuring the 
security policy defined for the security policy group for each connection. 

129. The method of claim 127, wherein the security policy provides encryption of 
20 traffic among the member networks and the rule is a firewall rule providing access control of the 

encrjrpted traffic among the member networks. 

130. The method of claim 127, wherein the system further includes a remote user 
terminal for accessing the member networks form a remote location, the method further 

25 comprising: 

establishing communication with the remote terminal; 

receiving authentication information fi*om flie remote terminal; and 

transmitting to the remote terminal the table with the dynamic membership information. 

30 131. The method of claim 130 furdier comprising automatically transmitting updates 

of the table to the remote terminal. 

132. The method of claim 101, wherein the central policy server and the first and 
second edge devices include first class units and second class units, each second class unit 

35 providing backup for a corresponding first class xmit upon failure of the first class unit. 

1 33. The method of claim 1 32, wherein each of the second class units is initially in an 
inactive state, and the method further comprises: 
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detecting a failure of a correspondiiig first class unit; and 

transitioning the second class unit from the inactive state to an activcstate upon detection 
of the failure. 

134. The method of claim 132 further comprising initializing each unit, wherein the 
initialization includes: 

assigning to the unit a role of the second class omit; 
searching for the corresponding first class unit; and 

initializing the unit as the second class unit if the corresponding first class unit is-detected. 

135. The method of claim 1 34 further comprising: 

assigning to the unit a role of the first class unit if tUe first class imit is not detected; 
searching for a corresponding second class unit; and 

initializing the xmit as the first class unit if the corresponding second class unit is detected. 

136. The method of claim 1 35 further comprising initializing the unit as a third class 
unit if the corresponding second class unit is not detected. 



137. The method of claim 132 further comprising: 
20 transitioning each of the first class units to an active ^te; 

receiving and storing first database configuration changes for each of the first class imits; 
transferring the configuration changes to the corresponding second class units; and 
storing the configuration changes on the corresponding second class units. 

25 138. The method of claim 1 37 further comprising: 

transitioning each of the first class units to an inactive state; 

receiving and storing second database configuration changes for the second class unit 
while the corresponding first class unit is in the inactive state; and 

transferring the second database configuration changes fi-om the second class unit to the 
30 first class unit after the first class unit re-transitions to the active state. 

139. The method of claim 132 further comprising: 
transmitting update information to each of the first class units; 
updating each of the first class imits; 
35 transmitting the update information &om each of the first class imits to each of the second 

class imits; and 

updating each of the second class units. 
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1 140, In a system including a-fir^t iietwork having a first set of isesources and a^second 

network remote from the first network having a second set of resources, the first networi: being 
associated v^dth a first edge device and a first diabase, and the second network being associated 
with a second edge device and a second database, the system further including a central policy 
S server in communication with the first and second edge devices, ihe central policy server being 
associated v\dth a central database, a method for managing policy services in the system 
comprising: 

storing configuration infomaation of the first and second edge devices in ^e 
central database, the central database being organized in a hierarchical object oriented structure; 
10 storing first policy settings in the first database; 

storing second policy settings in the second database; 

managing policies for the first network and the first set of resources fi'om the first 
edge device in accordance with the first policy settings stored in the first database; 

managing policies for the second network and the second set of resources fi"om 
15 the second edge device in accordance with the second policy settings stored in the second 
database; and 

defining the first and second policy settings and managing ihe first and second 
edge devices firom the central policy server. 

20 141. The method of claim 1 40, wherein the first and second databases are organized 

according to the hierarchical object oriented structure. 

142. The method of claim 140, whereinthe configuration information includes the first 
and second policy settings. 

25 

143. The method of claim 142, wherein the hierarchical object oriented structure 
includes a plurality of resource objects and policy objects for defining the first and second policy 
settings. 

30 144. The method of claim 1 43, wherein the central database and the first and second 

databases are Lightweight Directory Access Protocol (LDAP) databases storing each resource 
object and policr)^ object as an LDAP entiy. 

145. The method of claim 143, wherein the resource objects are selected fi-om aigroup 
35 consisting of devices, users, hosts, services, and time. 

1 46. The method of claim 1 45, wherein the devices include the first and second edge 
devices, each device being associated with a set of users and a particular host 
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147. The methodx)fclaim 1 45, \;\*erein the hosts include the first andisecond networks. 



148. The method of claim 143, wherein the policy objects are selected from a group 
consisting of bandwidth, firewall, administration, and virtual private network grouping. 

5 

1 49. The method of claim 148, wherein the virtual private network grouping includes 
a virtual private network associated with one or more sites, users, and rules. 

* 

1 50. The method of claim 149, vsiiereineach site includes one or more networks behind 
10 an edge device. 

151. The method of claim 149, wherein the rules are firewall rules providing access 
control over network traffic flowing through the virtual private network. 

13 1 52. A method for selective database synchronization comprising: 

storing in a central database configuration information for a plurality of edge devices in 
an organization, each edge device being associated with a network in the organization and 
configured to manage policies for the network; 

storing in a subordinate database a portion of the configuration ixiformation associated 
20 vsdth a particular edge device; and 

making a change to the portion of the configuration information associated with the 
particular edge device in the central database; 
creating a log of the changes; 
storing the log in the central database; 
25 transferring the changes to the particular edge device; and 

. updating the subordinate database based on the changes. 

153. The method of claim 152, wherein creating the log of flie changes fiirther 
comprises creating a user log for associating the change to a particular user making the change, 

30 the particular user being associated with the particular edge device. 

1 54. The method of claim 153 further comprising identifying the particular^edge device 
based on the particular user making the chaise. 

35 155. The method of claim 154, wherein the creating the log of changes fiirther 

comprises creating a device log for storing the change for the particular edge device. 

1 56. The method of claim 1 52 fiirther comprising: 
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receiving a status of the tranter firom the partidilar^ge device; and 
deleting the log from the central database if the^tus indicates a successiul transfer. 



157. The method of claim 152, wherein the central database and the subordinate 
5 database are Lightweight Directory Access Protocol XLDAP) databases storing configuration 

information as an LDAP entry identified by a distinguished name. 

158. The method of claim 152, wherem the configuration information is policy 
nuinagement information. 

10 

159. In a system including a first edge device managing policies for a first network 
according to first policy settings and a second edge devf ce managing policies for a second 
network according to second policy settings, the system further including a central policy server 
in communication with the first and second edge devices configured to define the first and second 

1 5 policy settings and manage the first and second edge devices from a single location, a method for 
integrated policy management comprising: 

determining a protocol associated with an incoming packet; 
making a forwarding decision for the packet based on policy settings associated with the packet; 
and 

20 forwarding the packet based on the policy settings. 

1 60. The method of claim 1 59, wherein the determining ftirther comprises: 
storing in a protocol database a mapping of protocols to data patterns found in a packet 

stream; and 

25 matching the packet to a protocol stored in the protocol database. 

161. The method of claim 1 59 frirther comprising maintainine in a resource engine a 
current mapping of resource group names to members in each grpiip. 

30 162. The method of claim 161 fiirther comprising storii^ in a policy buffer policy 

settings specified for a group associated with the packet 

1 63 . The method of claim 1 62, fiirther comprising matching the packet with the policy 
settings in the policy rules buffer based on membership information from the resource engine. 

35 

1 64. The method of claim 1 59 ftirther comprising authenjicating a user transmitting the 

packet. 
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1 165. The method of claim 159 fiHther comprising collectiiig ^tistics on packets 

flowing through the edge device. 

1 66. The method of claim 1 65, wherein the collecting ftnther^omprises: 

5 maintaining a byte count of the packets flowing through the-edge device; and 

organizing the byte coxmt according to resources associated with the packets. 

167. In a computer network including a first edge device coupled to a first private 
network and a second edge device coupled to a second private network, the first and-second^dge 

1 0 devices enabling secure conununication between the first and second private networks^ a method 
for gathering membership information -comprising: 

creating a first table with information of member networks reachable through the first 
edge device; 

storing the first table in a first database; 
15 creating a second table with information of member networks reachable through the 

second edge device; 

storing the second table in a second database; 

sharing the first table with the second edge device; and 

sharing the second table with the first edge device. 



20 



25 



1 68. The method of claim 1 67 further comprising: 
receiving a new route information; 

storing the new route information in the first database; and 

transmitting a portion of the new route information to the second edge device. 

169. The method of claim 168, wherein the portion of the new route information is a 
route name. 



1 70. The method of claim 1 68 further comprising: 
30 receiving the portion of Hic new route information; 

accessing the first database based on the portion of the new route information; 
retrieving the new route information fi-om the first database; and 
storing the retrieved route information in the second database. 

35 171. The method of claim 1 67, wherein communication between the first and second 

networks is managed according to a security policy associated with the networks. 
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1 172. The method of claim 171 5lirther<X)mprisiiig defi n ing the ^ecxirity policy for a 

security policy group, the group providing a hierarchical organization of the group including 
member networks, users allowed to access the member networks, and a rule controlling access 
to the member networks, 

5 

1 73. The method of claim 1 72, wherein each member network has fullxonnectivity 
with all other member networks and the security policy defined for the security policy group is 
automatically configured for each connection. 

10 174, The method of claim 172, wherein the security policy provides encryption of 

traffic among the member networks and the mle is a firewall rule providing access control of the 
encrypted traffic among the member networks. 

175. In a computer network including an edge device coupled to a private network, the 
1 5 edge device including a table with information of member networks reachable through the edge 
device, a method of providing information of the member networks to a remote user terminal, 
the method comprising: 

establishing conununication with the edge device; 

transmitting authentication information to the edge device; and 
20 downloading a client software for installation and execution on ihc remote user terminal, 

the client software allowing communication with the member networks reachable through the 
edge device, the client software further allowing downloading of the table with the information 
of the member networks. 

25 1 76. The method of claim 1 75 fiarther comprising automatically receiving updates of 

the table firom the edge device. 

1 77. The method of claim 1 75, wherein the client software includes a static portion and 
a dynamic portion, the static portion including an executable setup file and the dynamic portion 

30 including a template for being replaced with information specific to the downloading remote user 
terminal, and the method ftirther comprises replacing the dynamic portion with the table firom the 
edge device with the information of tiie member networks. 

178. In a system including a first network having a first set of resources and a second 
35 network remote fi*om the first network having a second set of resources, the first network being 

associated with a first edge device and a first database, and the second network being associated 
with a second edge device and a second database, the system fiuther including a central policy 
server in commimication with the first and second edge devices, the central pohcy server being 
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1 associated with a central database, a method for managiBg policy services in the system 
comprising: 

storing configuration infomiation of ihc first and second edge devices in the central 
database; 

5 storing first policy settings in the first database; 

storing second policy settings in the second database; 

managing policies for the first network and the first set of resources fi:*om the first edge 
device in accordance with flie first policy settings stored in the first database; 

managing policies for the second network and the second set of resourGes fi^om the second 
10 edge device in accordance with the second policy settings stored in the second database; and 

defining the first and second policy settings and monitoring health and status of the first 
and second edge devices from the central policy server. 

1 79. The method of claim 1 78, wherein the monitoring fiirther comprises: 

15 periodically receiving health and status information fi-om each of the edge devices; 

storing the health and status information in an archive database; and 
creating reports based on the health and status information, 

180. The method of claim 1 79, wherein each edge device collects and transmits health 
20 and status information in a predefined common log format. 

181. The method of claim 179, wherein the health and status information includes 
network flow information. 

25 1 82. The method of claim 181, fiirther comprising: 

maintaining a byte coimt of the packets flowing through the edge device; and 
organizing the b3rte count according to resources associated with the packets. 

183. The method of claim 179, wherein the health and status information includes 
30 statistics on use of each edge device's set of resources. 

1 84. The method of claim 183, wherein the reports indicate usage of the resources 
associated with a particular edge device over a period of time. 

35 185. The method of claim 1 79, wherein the monitoring furtherX:omprises deter mining 

when each of the edge devices is to transfer the health and status infomiation to flie log collecting 
and archiving module. 



-33- 



SUBSTITUTE SHEET (RULE 26) 



MSOOCIO: <WO .007eO04A3JA> 



wo 00/078004 PCT/USOO/16246 
1 1 86- In a system including a first edge device managing policies of a first netwoik, a 

second edge device managing policies of a second network, and a cei^ral policy server in 
communication with the first and second edge devices, the central policy server managing the 
fij-st and second edge devices fi-om a single location, a method for avoiding a single point of 
5 failure in the central policy server and the first and second edge devices, the method comprising: 
maintaining first class units for the central policy server and the first and second edge 
devices; 

maintaining second class units of the central policy server and the first and second edge 
devices, each of the second class units acting as a backup for a corresponding first class unit, each 
10 of the second class units being initially in an inactive state; 
detecting a failure of one of the first class units; and 

transitioning the corresponding backup unit from the inactive state to an active state upon 
detection of the failure. 

15 1 87. The method of claim 1 86 finther comprising: 

assuming a role of the second class unit; 

searching for the corresponding first class unit; and 

initializing as the second class unit if the corresponding first class unit is detected. 

20 188. The method of claim 1 87 fiirther comprising: 

assuming a role of the first class xmit if the first class vmit is not detected; 
searching for a corresponding second class unit; and 

initializing as the first class imit if the corresponding second class unit is detected. 

25 189. The method of claim 188 finther comprising initializing as a third class unit if the 

corresponding second class unit is not detected. 

1 90. The method of claim 1 86 finther comprising: 
transitioning each of the first class imits to an active state; 

30 receiving and storing first database configuration changes for each of the first class imits; 

transferring the configuration changes to the corresponding second class units; and 
storing the configuration changes on the corresponding second class units. 

191. The method of claim 1 90 fiuiher comprising: 

35 transitioning each of the first class units to an inactive state; 

receiving and storing second database configuration changes for the second class unit 
while the corresponding first class unit is in the inactive state; and 
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ta^nsferring the second database configuration changes from the second class unit to the 
first class unit after the first class unit re-transitions to the active state. 

1 92. The method of claim 1 86 further comprising: 
transmitting update information to each of the first class units; 
updating each of the first class units; 

transmitting the update information fi^om each of the first class units toeach of the second 
class units; and 

updating each of the second class units. 
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POLICY BASED NETWORK ARCHITECTURE 



FIELD OF THE INVENTION 

The present invention relates tox:omput«r networks, and more particularly, to devices and 
methods for providing efficient, integrated and scalable policy management services for remote 
private networks across the Intemeti 

BACKGROUND OF THE INVENTION 

The growth and proliferation of computers and computer networks allow businesses to 
efficiently communicate with their own components as well as with their business partners, 
customers, and suppliers. However, the flexibility and efficiencies provided by such computers 
and computer networks come with increasing risks, including security breaches from outside the 
corporation, accidental release of vital information from within it, and inappropriate use of the 
LAN, WAN, Internet, or extranet. 

In managing the growth of computer netwT>rks as well as addressing the various security 
issues, network managers often turn to network policy management services such as firewall 
protection. Network Address Translation, spam email filtering, DNS caching, Web caching, 
virtual private network (VPN) organization and security, and URL blocking for keeping network 
users from accessing certain Web sites through use of the organization's ISP. Each policy 
management service, however, generally requires a separate device that needs to be configured, 
managed, and monitored. Furthermore, as an organization grows and spreads across multiple 
locations, the devices maintained also multiply, multiplying the associated expenditures and 
efforts to configure, manage, and monitor the devices. 

The solution to this problem is not as simple as just integrating multiple network policy 
management functions into a single device at each location and allowing each location to share 
its policy information with other locations. In fact, there are many obstacles and challenges in 
adopting such an approach. For example, a scheme for specifying and distributing policy 
management information effectively across remote private networks of an entire organization 
generally requires a well designed object model. The synchronizing of multiple databases in the 
organization with updates to the policy management information may also be a complex problem. 
Moreover, managing the policy information efficiently for remote devices across an organization 
may present a challenge. Furthermore, collecting logs and statistics information from the remote 
private networks in a large distributed policy management system for efficient analysis and report 
generation is often a difficult task. Conventionally, only raw packet information is logged and 
saved, generally requiring time-consuming and custom-generated programs to be run on the raw 
data off-line to produce meaningful reports and statistics. 

TTiere are other challenges in providing a unified policy management system. For 
increased benefits, such unified policy management functions should be implemented as much 
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1 as possible in hardware. However, implementing policy management on a chip typically inquires 

an efficient design partitioning. Furthemiore, the unified policy management system should 
allow lor eftlcieni configuration, management, and updating of virtual private networks 
extending over different remote sites. 

5 Accordingly, there remains a need in the art for a network management solution that 

overcomes these and other obstacles of the prior art. 

SUMMARY OF THE INVENTION 

The present invention is directed to a unified policy management system where various 

1 0 policies, namely, the set of rules and instructions that determine the network's operation, may be 
established and enforced from a single site. According to one embodiment of the invention, the 
system includes a first edge device associated with a first network having a first set of resources 
that is configured to manage the policies for the first network according to the policy settings 
stored in a first database. The system also includes a second edge device associated with a 

1 5 second network having a second set of resources that is configured to manage the policies for the 
second network according to the policy settings stored in a second database. The first and second 
edge devices act as policy enforcers for their respective networks. The policies being enforced 
may include firewall policies, VPN policies, and the like. 

The system further includes a central policy server in conrmiunication with the first and 

20 second edge devices. The policy server is configured to define the first and second policy 
settings and manage the first and second edge devices from a single location. Thus, a network 
administrator need not multiply his or her eflbrts and associated expenditures in configuring and 
managing the policy enforcers individually. 

In alternative embodiments, the unified policy management system includes one or more 

25 of the following features: 

The central policy server may include a central database for storing configuration 
information of the policy enforcers. The central database as well as the databases associated with 
the policy enforcers are Lightweight Directory Access Protocol (LDAP) databases organized 
according to a hierarchical object oriented structure. This structure includes resource objects and 

30 policy objects for defining the policy settings for the policy enforcers. Such a structure helps 
simplify policy management by allowing the various elements of the policy management system 
to be defined and organized in an intuitive and extensible fashion. 

According to one embodiment of the invention, the resource objects include devices, 
users, hosts, services, and time. Devices are the policy enforcers at the edge of a particular 

35 private local network. Each device is associated with users and a host. A host is a network (e.g. 
a LAN subnet) in an organization. Services reflect the various services (e.g. HTTP, TELNET, 
FTP) provided by the policy server. Time is another dimension in controlling access to the 
network resources. 
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1 The central database stores the configuration information, including -policy settings, for 

all the policy enforcers. When a change is made to the configuration information, the policy 
serv er creates a log of such changes and stores it in the central database for later transferring to 
the policy enforcers. When the policy enforcers receive the log of changes, they update their 

5 respective databases accordingly and indicate to the policy server whether the updates have been 
. . successful. If they have been successful, the log of changes corresponding to these policy 
enforcers are deleted from the central database. 

The central policy server may further include a set of user application modules for 
allowing a user, such as the network administrator, to define the policy settings for the policy 

1 0 enforcers and further manage the policy enforcers from the single location. Preferably, the policy 
settings are associated with a plurality of resource objects including devices, users, hosts, 
services, and time. 

In one aspect of the invention, the set of application modules includes a centralized 
management sub-module for allowing installation and registration of the policy enforcers with 
15 the central policy server. 

In another aspect of the invention, the set of application modules includes a policy 
management sub-module for managing and viewing the resource objects fi-om the single location. 

In yet a further aspect of the invention, the policy server includes a set of user application 
modules for allowing a user to monitor the health and status of the policy enforcers. Each policy 
20 enforcer collects and transmits the health and status information to the policy server in a 
predefined common log format. The policy server may then create various reports based on this 
information. It should be appreciated, therefore, that the present invention allows on-the-fly 
monitoring of the resources in the organization, yielding further advantages of the invention over 
the prior art, which generally collected only raw data and required the tedious generation of 
25 reports. 

The functionalities of the policy enforcers in enforcing the policies for their respective 
networks may also be partitioned for effective hardware implementation. According to one 
embodiment of the invention, each edge device preferably includes a plurality of modules 
including a classification engine, a policy engine, and a packet forwarding engine. The 
30 classification engine determines a protocol associated with an incoming packet. The policy 
engine makes a forwarding decision for the packet based on policy settings associated with the 
packet. The packet forwarding module then forwards the packet based on the policy settings. 

In alternative embodiments, the module may further include a security engine for 
authenticating a user transmitting the packet and/or a statistics module for collecting statistics of 
35 packets flowing through the policy enforcer. 

Each of the networks in the system may also constitute private networks and each policy 
enforcer associated with the private network is configured to create a table with information of 
member networks reachable through the policy enforcer. The table is then shared with the other 
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1 member policy enforcers in the VPN. This allows the creation of VPNs whose member lists are 
dynamically compiled. 

In one particular aspeciof the invention, the communication between the fkst and second 
private networks is managed according to a security policy associated with the member networks. 

5 The security policy is preferably defined for a security policy group, referred to as a VPN cloud, 
- providing a hierarchical organization of the group. The VPN cloud includes member networks 
(hosts), users allowed to access the member networks, and a rule controlling access to the 
member networks. The hierarchical organization provided by the VPN clouds thus allows the 
network administrator to create fully meshed VPNs where every site within a VPNeloud has full 

1 0 connectivity with every other site. The network administrator need no longer manually configure 
each possible connection in the VPN, but only need to create a VPN cloud and specify the sites, 
users, and mles to be associated with the VPN. Each connection is then configured based on the 
configuration specified for the VPN cloud. The hierarchical organization thus facilitates the 
setup of a VPN with a large number of sites. 

1 5 In another aspect of the invention, the rule in the VPN is a firewall rule providing access 

control of the traffic among the member networks. Such firewall rules allow the administrator 
to have fine grained access control over the traffic that flows through the VPN, all within the 
realm of the encrypted access provided by such VPN. 

In a further aspect of the invention, a remote user accesses the member networks from a 

20 remote location using a remote user terminal. The terminal is configured with software for 
downloading the table with the dynamic membership information from the-edge device to which 
it is connected. Updates to the membership information are further automatically transmitted to 
the remote user terminal without requiring reconfiguration of the terminal. 

The policy server and policy enforcers, as well as other network <ievices may also be 

25 configured for high availability by maintaining a second class unit (backup unit) in addition to 
a first class unit (primary unit) for preventing a single point of failure. In one aspect of the 
invention, the backup unit is initially in an inactive state and later transitions to the active stale 
upon detection of a failure is the primary imit. 

In another aspect of the invention, each high-availability device discovers its status as a 

30 primary unit, a backup unit, or a stand-alone unit (third class unit) during initialization. 

In a ftirther aspect of the invention, the configuration information stored in the databases 
of the primary and backup units are synchronized by transitioning the first class unit to an active 
state, receiving and storing the first database configuration changes on the first class unit, 
transferring the configuration changes to the second class unit, and storing the configuration 

35 changes on the second class unit. When the primary imit transitions to an inactive state, the 
backup unit stores the second database configuration changes on the second class unit and 
transfers those changes to the primary unit after it re-transitions to the active state. 
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1 In stiJl another a^ecl of the invention, irodates to the primary and backup units, ^uch as 

software updates, are also synchronized transmitting the update information to the primary tmit, 
updating the primary unit, transmiuing the update from the primary unit to the backup unit, and 
updating the backup unit. Thus, the network administrator need not duplicate his or her efforts 
5 to update the backup units. 

BRH£F DESCRIPTION OF THE DRAWINGS 

These and other features, aspects and advantages of the present invention will be more 
fully understood when considered with respect to the following detailed description, appended 
10 claims and accompanying drawings wherein: 

FIG. 1 is a schematic block diagram of an exemplary unified policy management^ystem; 
FIG. 2 illustrates the hierarchical object-oriented structure of policies stored for an 
organization in accordance with the principles of the invention; 

FIG. 3 is a schematic block diagram of a policy server in the policy management system 
15 of FIG. 1; 

FIG. 4 is a schematic diagram of a central management sub-module in the policy server 
of FIG. 3; 

FIG. 5 is ah exemplary flow diagram of a device registration process carried out by the 
central management sub-module of FIG. 4; 
20 FIG. 6 is a screen illustration of an exemplary graphical user interface for registering a 

device; 

FIG. 7 is a screen illustration of an exemplary global monitor user interface presenting 
device health and status information; 

FIG. 8 is a screen illustration of an exemplary graphical user interface provided by a 
25 policy management sub-module in the policy server of FIG. 3; 

FIG. 9 is a screen illustration of an exemplary graphical user interface for managing 
system devices; 

FIG. 10 is a screen illustration of an exemplary graphical user interface for managing 
system hosts; • 

30 FIG. 1 1 is a screen illustration of an exemplary graphical user interface for managing 

system services; 

FIG, 1 2 is a screen illustration of an exemplary graphical user interface for managing time 

groups; 

FIG. 13 is a screen illustration of an exemplary graphical user interface displaying a 
35 plurality of VPN clouds; 

FIG. 14 is a screen illustration of an exemplary graphical user interface for adding a new 

firewall policy; 
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1 FIG. 15 is a schematic functional block diagram of policy enforeers i^dating tteir 

respective VPN membership information; 

FIG. 1 6 is a block diagram of components in a self-extracting executableforxlownloading 
by a remote VPN client; 

5 FIG. 1 7 is a functional block diagram for downloading the self-extracting executable of 

FIG. 16; 

FIG. 18 is a schematic block diagram of a policy enforcer in the policy management 
system of FIG. 1; 

FIG. 19 is a more detailed schematic block diiagram of a policy engine in the policy 
10 enforcer of FIG. 18; 

FIG. 20 is a more detailed schematic block diagram of a protocol classification engine of 
the policy enforcer of FIG. 18; 

FIG. 21 is a more detailed schematic block diagram of an Internet protocol security engine 
in the policy enforcer of FIG. 18; 
15 FIG. 22 is a schematic layout diagram of a common log format according to one 

embodiment of the invention; 

FIG. 23 is a block diagram of an LDAP tree structure according to one embodiment of 
the invention; 

FIG. 24 is a more detailed block diagram of a branch of the LDAP tree of FIG. 23; 
20 FIG. 25 is a flow diagram for logging and propagating LDAP changes to policy enforcers; 

FIG. 26 is a schematic block diagram of a high availability system including a primary 
unit and a backup unit; 

FIG. 27 is a flow diagram of an exemplary status discovery process conducted by a high 
availability unit; 

25 FIG. 28 is a flow diagram of a process for maintaining configuration information 

synchronized in the primary and backup units of FIG. 26; 

FIG. 29 is an exemplary flow diagram of updating the primary and backup imits of FIG. 
26 when they are both functional; and 

FIG. 30 is an exemplary flow diagram of updating the primary and backup units FIG. 26 
30 when the primary is not fimctional. 

DETAILED DESCRIPTION OF THE INVENTION 

L UNIFIED POLICY MANAGEMENT SYSTEM ARCHITECTURE 

FIG. 1 is a schematic block diagram of an exemplary unified policy management system 
35 according to one embodiment of the invention. As illustrated in FIG. 1, private local networks 
102, 104, and 106 are all coupled to a public network such as the Internet 108 via respective 
routers (generally identified at 110) and Internet Service Providers (ISPs) (not shown). Also 
coupled to the public Internet 108 via the ISPs are web surfers 1 12, dial-up network users 1 14, 
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1 servers providing unauihorized web sites 1 16, email spammers 1 1 8 sending out unsolirited junk 
email, and remote VPN clients HO seeking access to the private local netw^orks 102. 

According lo one example, local netv^ork 102 connects users and resources, such 
as workstations, servers, primers, and the like, at a first location of the organization, 3uch as the 

5 organization's headquarters, and local network 104 connects users and resources at a se<:ond 
location of the organization, such as a branch office. Furthermore, local network 106 connects 
users and resources of a customer of the organization requiring special acc^s to the 
organization's users and resources. Authorized dial-up network users 1 14 of the organization 
arc respectively situated at remote locations from the first and second local networks, and also 

IX) require special access to the organization's users and resources. Furthermore, web surfers 112 
communicate with the organization's web server 120 over the public Internet 108 and access the 
organization's web site. 

Local network 102 includes a policy server 122 for defining and managing network 
services and policies for the organization. The network policies are a set of rules and instructions 

15 that determine the network's operation, such as firewall, VPN, bandwidth, and administration 
policies. The firewall policies decide the network traffic that is to be allowed to flow fi-om the 
public Intemet 1 08 into the local networks 102, 104, and the traffic that is to be blocked. The 
bandwidth policies determine the kind of bandwidth that is to be allocated to the traffic flowing 
throuyh tlic local networks. The VPN policies determine the rules for implementing multiple site 

20 connectivity across the local networks. The administration policies decide the users that have 
access to administrative functions, the type of administrative functions allocated to these users, 
and the policy enforcers 124. 126 on which these users may exercise such administrative 
functions. The firewall, VPN, bandwidth, and administration policies for the entire organization 
are preferably stored in a policy server database 130 maintained by the policy server 122. 

25 Each local network 1 02, 1 04 also includes an edge device, referred to as a policy enforcer 

124, 126. for controlling access to the network. Each policy enforcer 124, 126 manages the 
network policies and services for the users and resources of their respective local networks 102, 
1 04, as permitted by the policy server 1 22. Respective portions of the policy server database 1 30 
are copied to the policy enforcer databases 1 32, 1 34 for allowing the policy enforcers to manage 

30 the network policies and services for the local networks 102, 104. 

According to one embodiment of the invention, the policy server 1 22 and policy enforcers 
124, 126 may be implemented in a similar fashion as the FORT KNOX series of policy routers 
made by Alcatel Internetworking, Inc., of Milpitas, California. 

35 11. OBJECT MODEL FOR NETWORK POLICY MANAGEMENT 

According to one embodiment of the invention, the policy server database 1 30 and policy 
enforcer databases 132, 134 are LDAP databases adhering to a unified hierarchical object 
oriented structure. The LDAP directory service model is based on entries where each entry is a 
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1 collection of auributes referenced by adisiinguished name <DN). Each of tfae attributes includes 
a type and one or more values. The type is typically a mnemonic -string, ^uch as "o" for 
organization, "c" for country, or "mail" for email address. The values depend on the type of 
attribute. For example, a "mail" attribute may contain the value "babs'Siumicb^du" A 

5 -^jpegPhoto^' anribute may contain a photograph in binary JPEG/JFIF format. Additional details 
of the LDAP directory service model are defined in RFC 1777 "The Lightweight Directory 
Access Protocol" (W. Yeong, T. Howes, and Kille, Network Working Group, March 1995) and 
"LDAP Programming: Directory-enabled Applications with Lightweight Directory Access 
Protocol" (T. Howes, and M. Smith, Macmillan Technical Publishing, 1 997), incorporated herein 

10 by reference. 

The entries in the LDAP database are preferably arranged in a hierarchical tree-like 
structure reflecting political, geographic, and/or organizational boundaries. Entries representing 
countries appear at the top of the tree. Below them are entries representing states or national 
organizations. Below the states or national organizations may be entries representing people, 
15 organization units, printers, documents, and the like. 

FIG. 2 is a schematic layout diagram of a unified hierarchical object oriented structure 
adhered by the policy server database 130 according to one embodiment of the invention. The 
policy enforcer databases 1 32, 1 34 adhere to a similar structure except for a few-differences. For 
example, the policy enforcer databases preferably do not contain a policy server domain object 
20 20 1 and related policy server objects, nor a policy domain object 240, 

As illustrated in FIG. 2, each object in the structure is preferably stored as an LDAP entry. 
At the top of the hierarchy is the policy server domain object 201 including various poHcy server 
resources and a plurality of policy domains objects (generally referenced at 204). Each policy 
domain object 240 is a grouping of policy enforcers that share common policies. Each policy 
25 domain object 240 includes a resource root object 200 and a group root object 202. All policy 
management functions are preferably implemented in terms of the resource objects which include 
devices 204, users 206, hosts 208, services 210, and time 220. Thus, a firewall policy may be 
defined by simply assigning the particular devices, users, hosts, services, and time applicable to 
the policy. The devices, users, hosts, and services are preferably organized in groups 212, 214, 
30 216, and 218, respectively, having a group name, description, and member information for a 
more intuitive way of addressing and organizing the resources. 

Users 206 are preferably associated with a user domain providing a secure and efficient 
means of authenticating the user. Each user domain has a single policy enforcer who is authorized 
to authenticate the user. Thus, user domains ensure that the authenticating agent is generally 
located in the same local network as the user. This helps eliminate the cost of network 
dependency or network latency during the user authentication process. It should be noted, 
however, that users may also constitute authorized dial-up users 1 1 4 and users firom the customer 
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1 network 1 06. These users contact a remote authenticating agent which proxies the authentication 
back to the appropriate policy enforcer. 

Hosts 208 are the various networks present in an organization. For instance, a particular 
LAN subnet may be specified as a host in the system. Hosts 208 are preferably organized based 
5 on their physical locations wiihin the organization. A host's physical location is identified by the 

device (policy enforcer) 204 associated v^th the host. 

Services 2 1 0 reflect the various services provided by the policy server 1 22. Such services 
include, for example, multimedia streaming/conferencing, information retrieval, security and 
authentication, database applications, mail applications, routing applications, standard 
10 communication protocols, and the like. Attributes associated with each service preferably 
include a service name, description, type (e.g. HTTP, HTTPS, FTP, TELNET, SMTP, R«al 
Networks, and the like), and group. 

Devices 204 are the policy enforcers 124, 126 at the edge of a particular local network. 
Each device/policy enforcer preferably includes users 206 and a host/network 208 that is 
1 5 managed by the policy enforcer. 

Time 220 is another dimension in controlling access to the network resources. Various 
lime objects covering a range of times may be created and used in creating the firewall policies. 

Similar to resources, network policies are also preferably defined in terms of objects for 
a more efficient and intuitive definition of the policies. Policies are defined by the administrators 
20 and implemented by the policy enforcers 124, 126 on the network traffic flowing between the 
public Internet 108 and the local networks 102 and 104. 

According to one embodiment of the invention, a policy object 222 includes a bandwidth 
policy 224, firewall policy 226, administration policy 228, and VPN policy 230. The VPN policy 
230 defines a security policy for the member networks and includes one or more VPN clouds 
25 232. Each VPN cloud 232 is an individual VPN or a group of VPNs defining a security policy 
group which includes a list of sites 234 and users 236 who can communicate with«ach other. 
A site is preferably a set of hosts/networks physically located behind one of the policy enforcers 
124, 126. In other words, a site is a definition of a network which includes the policy enforcer 
that is associated with it. The policy enforcers for the sites act as VPN timnel endpoints once the 
30 hosts under the sites start communicating. These communications are governed by a set of rules 
238 configured for each VPN cloud. The rules 23 8 may govern, among other things, VPN access 
permissions and security features such as the level of encryption and authentication used for the 
connectivity at the network layer. 

The object oriented structure of FIG. 2 thus allows the network administrators to define 
35 policies in an intuitive and extensible fashion. Such policies may be defined by simply 
associating resources lo ihe policies. This allows for a policy-centric management model where 
the administrator is given the impression that a single logical server provides the firewall. 
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1 bandwidth management, and VPN services across the enterprise. The fact that the policy is 
enforced on individual policy enforcers indifferent locations is transparent to tte adminiBtrator. 

III. POLICY-BASED NETWORK ARCHITECTURE 

5 FIG. 3 is a more detailed schematic block diagram of the policy server 122 according to 

one embodiment of the invention. The policy server 122 preferably includes a management 
module 302 that allows centralized control over the policy enforcers 124, 126 from a -single 
console. The policy server 122 further includes a log collecting and archiving module 304 and 
a policy server reports module 316. The log collecting and archiving module 304 collects 

10 information about the status and usage of resources from the policy enforcers 124, 126 as well 
as from the management module 302, and stores ihem in an archive database 318. The policy 
server reports module 3 1 6 uses the collected logs and archives to generate reports in an organized 
report format. 

Referring again to the management module 302, the management module 302 preferably 
1 5 includes four sub-modules aiding in the centralized control, namely, a centralized management 
sub-module 306, policy management sub-module 308, secure role-based management sub- 
module 3 1 0, and multiple site connectivity management sub-module 312. 

The centralized management sub-module 306 enables a network administrator to install 
and manage individual policy enforcers from a central location. The network administrator 
20 preferably uses a web-based graphical user interface to define the policy enforcer's network 
configuration and monitor various aspects of the device, such as device health, device alarms, 
VPN connection status, and the like. 

The policy management sub-module 308 provides the netv^ork administrator with the 
ability to create policies that span multiple functional aspects of the policy enforcer (e.g. firewall, 
25 bandwidth management, and virtual private networks), multiple resources (e.g. users, hosts, 
services and time), and multiple policy enforcers. 

The secure role-based management sub-module 3 1 0 provides role-based management to 
enable administrators to delegate administrative responsibilities to other administrators. This 
sub-module preferably provides for maximimi security when it comes to accessing the 
30 management functions. 

The multiple site connectivity management sub-module 312 allows the network 
administrator to set-up secure communication channels between two or more remote sites. In 
doing so, this sub-module leverages the centralized management sub-module 306, policy 
management sub-module 308, dynamic routing capabilities of the policy enforcers 124, 126, and 
35 the management infrastructure to provide virtual private networks across the enterprise with fine 
grained access control. 

FIG. 4 is a more detailed schematic diagram of the central policy management sub- 
module 306 according to one embodiment of the invention. The sub-module includes a policy 
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1 server installation wizard 404 providing an interactive user interface to aid the installation of the 
policy server 122. In this regard, the network administrator has access to a personal computer 
connected to a LAN port of the policy server 122 via a cross over cable, hub, or the like. The 
network administrator connects to the policy server 122 by preferably typing-in a URL of the 

5 policy server 1 22 into a standard Internet browser such as Microsoft Internet Explorer. The URL 
is preferably of the form of '•hiip://<ipaddress>:88/index.hlmr' where <ipadtiress> is the IP 
address that is to be assigned to the policy server. The IP address is automatically assigned to 
• the policy server when the browser attempts to contact the address. When the administrator's 
personal computer sends an address resolution protocol request for the IP address, the policy 

10 server detects that a packet directed to port 88 is not claimed, and assumes the IP address. 

Once connected, the policy server installation wizard 404 invokes the interactive user 
interface to assist the administrator in setting up the policy server 122. Among other things, the 
policy server installation wizard 404 prompts the administrator to sp>ecify a server name, server 
IP address, and router IP address. Furthermore, the policy server installation wizard 404 prompts 

15 the administrator to select one of various default policies for creating default firewall, VPN, 
bandwidth, and administrator policies. These policies are then replicated on each new policy 
enforcer registering with the policy server 122. 

The centralized management sub-module 306 further includes a policy enforcer 
installation wizard 406 providing an interactive user interface to aid the installation of the policy 

20 enforcers 1 24, 1 26. As with the installation of the policy server 1 22, the access to the wizard 406 
is preferably web-based using the network administrator's personal computer. 

Once connected, the policy enforcer installation wizard 406 invokes the interactive user 
interface to assist the network administrator in setting up a particular policy enforcer 124, 126. 
Among other things, the policy enforcer installation wizard 464 prompts the administrator to 

25 specify the policy server IP address, policy enforcer IP address, and router IP address. The policy 
enforcer then registers with the policy server 122 by invoking a URL on the policy server with 
basic bootstrap information of its own. The registration of the policy enforcer allows the 
initialization of the policy enforcer's database 132, 134 with the configuration information, as 
well as the monitoring of the policy enforcer's status and health by the policy server 122. 

30 Prior to registering the policy enforcer with the policy server 122, the network 

administrator preferably pre-registers the policy enforcer on the policy server. Such pre- 
registering allows the creation of a placeholder node on the policy server for the policy enforcer 
data for when the policy enforcer does in fact register. In this regard, the centralized management 
sub-module 306 includes a configuration interface 410 allowing the pre-registration of a new 

35 policy enforcer. 

FIG. 5 is an exemplary flow diagram of a policy enforcer pre-registration and registration 
process according to one embodiment of the invention. In step 401, the policy enforcer is 
connected to the network and installed at its actual physical location using the above-described 
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1 policy enforcer installation wizard 406. The network administrator, possessing the new device's 

serial number, pre-registers the policy enforcer by adding the new policy -enforeer to atievice 
group in step 403 . In this regard, the configuration interface 4 1 0 invokes an interact! vegraphical 
interface, such as the one illustrated in FIG. 6, allowing the network administrator to«nter a 

5 device name 415, serial number 417, and location information 419, and further allowing the 
administrator to select a device group 421 to which the new policy enforcer is to belong. 
Actuation of an apply button 423 causes the new policy enforcer, in step 405, to contact the 
policy server 1 22 by preferably invoking a URL on the policy server. Once the policy server has 
been contacted, the new policy enforcer transmits its registration packet to the policy server. The 

1 0 registration packet includes at least a serial number of the new policy enforcer, as well as the IP 
addresses of the LAN. WAN, and DMS on the policy enforcer. In step 407. the centralized 
management sub-module 306 compares the serial number of the new policy enforcer with the list 
of policy enforcers pre-registered with the policy server 122. If a match is found, the policy 
serN'er 122 proceeds with the registration process by packaging, in step 409, the settings selected 

1 5 for the policy enforcer during its installation process, preferably into an LDAP Data Interchange 
Format (Idif) file. In step 41 1, the file is u-ansmitted to the policy enforcer, preferably over an 
HTTPS channel, by invoking a common gateway interface (CGI) on the policy enforcer. The 
policy enforcer then uses the file to initialize its configuration database, such as database 132, 
134, in step 413. 

20 Referring again to FIG. 4, the centralized management sub-module 306 also includes a 

global monitor user interface 402 and a data collector program 412, respectively displaying and 
collecting the health and status of all the policy enforcers managed by the policy server 122. The 
data collector program 412 receives health and status information fit)m each of the up-and- 
running policy enforcers it manages, and passes the relevant information to the global monitor 

25 user interface. A health agent running as a daemon in each of the policy enforcers being 
monitored periodically collects data from the device and analyzes its health status. The collected 
data is then transferred to the policy server 122 when requested by the data collector program 
412. 

FIG. 7 is a screen illustration of an exemplary global monitor user interface 402 
30 presenting various types of health and status infomation. Such information may relate to the 
health of the device, such as system load 712 and network usage information 714. The 
information may also relate to current alarms 716 on the device including alarm name, type, 
description, and the like. The inforaiation may further relate to current VPN connections 718 
including connection type, source/destination, duration, and VPN traffic volume. 
35 Referring again to FIG. 3, the policy management sub-module 308 allows for policy 

management of the policy enforcers 124, 126. As discussed above, all policy management 
functions are implemented in terms of resource objects stored in the policy databases 130, 132, 
134 including users, devices, hosts, services, and time. Preferably, all resources are associated 
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1 with default policy settings selected by the administrator during the installation process.* The 

network administrator views, adds, and modifies the policies centrally via a graphical user 
interface provided by the policy management sub-module 308. This allows for a policy-t^entric 
management model where the administrator is given the impression that a single logical server 

5 provides the firewall, bandwidth management, and VPNiservices across the enterprise. The fact 
that the policy is enforced on individual policy enforcers in different locations is transparent to 
the administrator. 

FIG. 8 is a screen illustration of an exemplary graphical user interface provided by the 
policy management sub-module 308. The interface includes a resource palette 718 including a 

10 list of resource tabs including a users tab 718a, devices tab 718b, hosts tab 718c, services tab 
718d. and lime tab 718e. The resource palette allows the administrator to add and modify 
resource definitions from a single console. 

Selection of the users tab 718a causes a display of the user groups 722 defined for the 
system. New users may be added to the group by selecting a particular group and defining 

15 various attributes of the user such as a login name, full name, policy enforcer to which the user 
belongs, authentication scheme, password, and the like. 

Selection of the devices tab 71 8b causes a display of various device management icons 
for managing the policy server 122 and the policy enforcers 124, 126 as is illustrated in FIG. 9. 
A policy server systems settings icon 750 allows the network administrator to view and modify 

20 system settings like LAN, WAN^MS IP addresses of the policy server 122. A policy server 
archive options icon 752 allows specification of reporting and other database archive options at 
the policy server 1 22. A global URL blocking icon 754 allows the administrator to specify a list 
of unauthorized web sites 1 16 to be blocked by all the policy enforcers 124, 126 of the system. 
Similarly, a global spam list icon 756 allows the administrator to specify a list of email addresses 

25 of spammers 11 8 to be blocked by all the policy enforcers. 

The administrator may view information on all the policy enforcers 1 24, 1 26 by selecting 
icon 758. Information on a specific policy enforcer may be viewed by selecting a specific policy 
enforcer 760 under a particular device group 761. Such information includes system settings 
information 762, URL blocking infomiation 764, spam list information 766, and the like, that is 

30 specific to the selected policy enforcer. For instance, selection of the policy enforcer's URL 
blocking information 764 icon causes a display of various categories 768 of URLs that the 
network administrator may select to block for the selected policy enforcer. 

Selection of the hosts tab 7 1 8c causes a display of various hosts (networks) of the system 
as is illustrated in FIG. 10. A host is organized based on its physical location and is further 

33 associated with a particular policy enforcer 124, 1 26. Hosts are associated with various attributes 
including a unique name 770, an IP address of the network 772, and a subnet mask 774. In 
addition, the administrator may specify whether the host is an external host 776 belonging to a 
network that is not administered by the policy server 122. If the host is an external host, the 
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1 administrator specifies an IP adxkess 778 of the external tievice to which the ho^t belongs. A 
device field 780 allows the administrator to enter the policy enforcer's name to which the host 
belongs. Each host is further associated with a particular group 782 assigned by the 
administrator. 

5 Selection of the services tab 7 1 8d causes a display of various service groups supported 

by the policy server 122 as is illustrated in FIG. 1 1 . Such service groups include, for example, 
multimedia streaming/conferencing, infonnation retrieval, security and authentication, mail 
applications, routing applications, database applications, standard communication protocols and 
the like. Users may also add new service groups as desired. 

j() Each service is associated with a name 784, description 786, and service type 788 (e.g. 

HTTP. HTTPS. FTP. TELNET. SMTP, Real Networks, and the like). Furthermore, each service 
is associated with a service group 790. Based on the type of service, additional information may 
also be specified for the service. For instance, for an HTTP service, the administrator may 
specify whether URL blocking 792 is to be enabled. 

J 5 Selection of the time tab 7 1 8e causes a display of various time group icons 794 covering 

a range of times to be used in the firewall policies as is illustrated in FIG. 12. For instance, 
selection of a work time group icon allows the network administrator to set the days and times 
which are to be set as working days and hours. 

Referring again to FIG. 8, the interface also includes a policy canvas 720 including a list 

20 of policies available to the system. A policy definition is preferably an association of a set of 
resources that may be dragged from the resource palette 71 8 and dropped onto the policy canvas 
720. 

Selection of a firewall tab 720a causes a display of all the firewall policies defined for a 
particular policy domain including one or more policy enforcers. The network administrator 

25 decides the domain to which a policy enforcer is to belong during pre-registration of the policy 
enforcer. The interface allows the network administrator to view, add, and modify the various 
policies from the policy server 122 and effectuate the changes on the policy enforcers 124, 126 
without the need to make such changes individually in each policy enforcer. 

According to one embodiment of the invention, each firewall policy includes a policy 

30 identifier (ID) attribute 724 for identifying a particular policy rule in the list of policies. An order 
number attribute 726 for the policy rule indicates the sequence in which the policy is to be 
applied. In this regard, the policy enforcer 1 24, 1 26 for the local network takes one rule at atime, 
in sequence, compares it against the network traffic, and preferably applies the first rule that 
matches the network traffic. 

35 Each firewall policy also includes a description attribute 728 for describing the firewall 

policy to be applied. For instance, the description may indicate that the policy allows spam 
blocking, URL blocking, VPN key management, and the like. An action flag attribute 730 
indicates whether traffic is to be allowed or denied for the indicated policy. An active flag 
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1 attribute 732 indicates whether the poHcy has been activated or de-activated.' Thus, the netv^oric 

administrator may create a policy and activate it at a later time. A policy that has been xie- 
activated preferably has no effect on the netv^ork traffic. 

Each firew^all policy further includes a user attribute 734, sour<:e attribute 736,'Service 
5 attribute 738, destination attribute (not shown), and time attribute (not shown). Each of these 
attributes is preferably represented by a group name or a resource name. The name acts as a 
pointer to an entry in the group root object 202 or resource root object of the LDAP database 1 30, 
. 132, or 134. 

Preferably, the user attribute 734 indicates the user groups and users that are eligible for 
10 the policy. The source attribute 736 indicates a point of origination of the network traffic 
associated with the user. The services attribute 738 indicates the services to the allowed or 
denied by the policy. The destination attribute indicates a specific LAN, WAN, DMS segment 
or specific hosts where the specified services are to be allowed or denied. For example, to 
configure SMTP pop services on a mail server, the host may be the IP address where the mail 
1 5 server is running, and the services specified is SMTP. The time attribute indicates a time slot in 
which the policy is to be effective. 

In addition to the above, each firewall policy also includes an authentication attribute (not 
shown) indicating an authentication scheme for the policy (e.g. none, LDAP, SecurlD, RADIUS, 
WinNT, or all). 

20 FIG. 1 4 is a screen illustration of an exemplary graphical user interface for adding a new 

firewall policy to the policy domain upon actuation of an add button 725. Existing firewall 
policies may also be modified or deleted by actuation of a modify button 727 and a delete button 
729, respectively. 

As illustrated in FIG. 14, a new firewall policy may be defined by simply adding a 
25 ^ description of the policy in a description area 728a, selecting an action to be applied to the 
matching network traffic in an action box 730a, and indicating in an active area 732a whether the 
policy is to be active or inactive. Furthermore, the network administrator specifies the user, 
source, services, destination, and time resources in a user area 734a, source area 736a, services 
area 738a, destination area 739a, and time area 741, respectively. The network administrator 
30 further selects an authentication scheme for the policy in an authentication area 743. Upon 
actuation of an OK button 745, appropriate entries of the policy server database's LDAP tree are 
suitably changed to reflect the addition of the new policy. The change is also transmitted to the 
respective policy enforcers as is described in fiirther detail below. 

Referring again to FIG. 8, selection of the bandwidth tab 720c allows the display, 
35 addition, and modification of various bandwidth policies determining the kind of bandwidth to 
be allocated to a traffic flowing through a particular policy enforcer. Different bandwidths may 
be specified for different users, hosts, and services. 
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1 Selection of the administration tab 720d allows the display, addition, and modification 

of various administrative policies allowing a head network administrator to delegate 
administrative responsibilities to other administrators. In this regard, the tead network 
administrator specifies administration policies that determine which tisers have access to what 

5 functions, and for what devices. Preferably the administration policies include similar attributes 
as the firewall rules except for the specification of a role attribute. Extra administrative 
privileges may be afforded to certain users depending on their role. 



10 



IV, VIRTUAL PRIVATE NETWORK HAVING AUTOMATIC 
REACHABILITY UPDATING 



Referring again to FIG. 3, the multi-site connectivity management module 312 allows the 
creation of dynamically routed VPNs where VPN membership lists are automatically created 
without statically configuring the membership information by the network administrator. Thus, 
once the administrator configures a VPN from one policy enforcer's LAN to another, routing 

15 protocols such as RIPvl or RIPv2 running on the LAN interfaces leam about the networks 
reachable through their respective interfaces. These networks then become the VPN's members, 
and the policy enforcers 124, 126 on either side of the VPN create membership tables using the 
learned routes. The membership information is preferably exchanged between the policy 
enforcers 124, 126 through the LDAP databases 132, 134. Thus, the combined use of routing 

20 protocols and LDAP allows the creation of VPNs whose member lists arc dynamically compiled. 

Referring again to FIG. 8, the network administrator configures VPN policies for multiple 
site connectivity using the resource palette 7 1 8 and policy canvas 720. Selection of the VPN tab 
720b in the policy canvas 720 causes the display of a collection of VPN clouds 270 already 
configured for the system as is illustrated in FIG. 13. As described above, a VPN cloud is an 

25 individual VPN or a group of VPNs for which a security policy may be defined. Each VPN cloud 
includes a list of sites under a sites node 234 and users under a users node 236, who can 
communicate with each other. A site is a set of hosts that are physically behind one of the policy 
enforcers 124, 126. The policy enforcers for the sites preferably act as VPN tunnel endpoints 
once the hosts under the sites start communicating. 

30 The users in the VPN cloud are the users who may access the hosts associated with the 

sites 234. The users access the hosts as VPN clients using VPN client software installed in each 
user's personal computer as is described in further detail below. 

Each VPN cloud 270 fiirther includes a firewall rales node 276 including firewall rules 
to be applied all the connections in the cloud. The rules may govem, among other things, VPN 

35 access permissions, security features such as the level of encryption and authentication used for 
the connectivity at the network layer. 

The hierarchical organization provided by the VPN clouds thus allows the network 
administrator to create fully meshed VPNs where every site within a VPN cloud has full 
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1 connectivity with every other site. The network administrator need no longer manual ly-configure 

each possible connection in the VPN, but only need to create a VPN cloud and specify the sites, 
users, and rules to be associated with the VPN. Each connection is then configured based on the 
configuration specified for the VPN cloud. The hierarchical organization thus facilitates the 

5 setup of a VPN with a large number of sites. 

The network administrator preferably adds a new VPN cloud by actuating an add button 
280. In response, the policy server 122 automatically CFeates the sites node 272, users node 274, 
and rules node 276 under the VPN cloud. The administrator then specifies the sites and users in 
the VPN. 

10 According to one embodiment of the invention, the rules node 276 initially includes a 

default VPN rule 278 corresponding to the policy settings selected by the network administrator 
during setup of the policy server 122. The default VPN rule 278 allows unrestricted access 
between the hosts in the VPN. 

The administrator may implement the access control within the VPN cloud by deleting 

1 5 the default rule 278 and adding specific firewall rules to the VPN. Such firewall rules allow the 
administrator to have fine grained access control over the traffic that flows through the VPN, all 
within the realm of the encrypted access provided by such VPN. The firewall rules are applied 
to the cleartext packet after it is decrypted or before it isencr>'pted. 

According to one embodiment of the invention, the administrator selects the default rule 

20 278 to effectuate such changes to the default rule. Selection of the default rule invokes a 
graphical user interface similar to the one illustrated in FIG. 8. The network administrator then 
fine tunes the access to the VPN by defining the firewall rules applicable to the VPN. The 
parameters in these firewall rules are preferably identical to the general firewall rules illustrated 
in FIG. 8. 

25 Once a VPN cloud is configured, VPN membership information is dynamically created 

by the policy enforcers 124, 126 in the VPN. In this regard, each VPN site includes a tag 
identifying the hosts included in the site. At runtime, the policy enforcers 124, 126 for the 
respective sites associate IP addresses to the tag identifying the hosts in each site. This allows 
the IP addresses to be dynamically discovered without requiring static configuration of the IP 

30 addresses. 

After the creation of the membership tables, any changes in the routing information is 
detected and notified to the member policy enforcers using a publish/subscribe process. The 
actual changes are retrieved by a policy enforcer by querying the LDAP database on the particular 
network that corresponds to the changed routing information. 
35 FIG. 1 5 is a schematic functional block diagram of policy enforcers 1 24, 126 at opposite 

ends of a VPN timnel updating their respective routing information. As illustrated in FIG. 15, 
each policy enforcer 124, 126 includes a gated module 252, 261 configured as a daemon to run 
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1 one or more routing protocols for exchanging routes on the network. Such routing protocols may 

include RIPvl, RlPv2, OSPF, and the like. 

When a network administrator wishes to add a new route to the private local networic 1 02 
connected to policy enforcer 1 24, the administrator submits, in step 24 K the new route to abated 

5 module 252 in the policy enforcer 124. This is typically done by configuring a downstream of 

—the policy enforcer to have an additional network. This information is then propagated by 
standard routing protocols to the gated module 252 of the policy enforcer 1 24. For example, the 
policy server 1 22 may publish the new route to the policy enforcer 1 24 with which the new route 
is to be associated. The route may be specified, for example, by an LDAP statement such as 

1 0 "LAN_Group@PR 1 /' which specifies a new route from a policy enforcer PR 1 to a LAN named 
LAN_Group. The gated module 252, in step 242, writes the new route to a kernel 253 of the 
policy enforcer including a VPN driver 254 so that the polic> enforcer 124 can property direct 
appropriate messages along the new route. Furthermore, the gated module 252, in step 243, 
writes the new route to its LDAP database 132. 

1 5 The gated module 252 also provides, in step 244, the name of the new route to a 

distinguished name monitor (DNMonitor) daemon 255 configured to listen for updates in the 
LDAP database 132. The DNMonitor in turn notifies, in steps 245a, 245b, a VPN daemon 256 
and a policy deployment point (PDP) engine 257 of the change in the LDAP database 132. The 
PDP engine then updates the modules that enforce the policies, with the change. 

20 The VPN daemon 256, in step 246, uses the route name to access the LDAP database 1 32 

to get the complete route information, a list of all VPNs to which the nevv route belongs, and a 
list of all other policy routers connected to those VPNs. In step 247. the VPN daemon 256 
proceeds to send the new route name to each of the other policy routers. 

When policy router 126 receives a new route name from policy router 124, its network 

25 daemon 258, in step 248, accesses the LDAP database 132 in the sending policy router 124 to 
obtain the complete new route information. If the new route belongs to more than one VPN and 
has different parameters for the different VPNs, routers on the different VPNs retrieve different 
information corresponding to the individual VPNs. 

In step 249, the network daemon 258 writes the new route information obtained in its own 

30 LDAP database 134 and provides it to its own DNMonitor module. As in the sending policy 
router 1 24, the DNMonitor module 259 in the receiving policy router 1 26 provides the new route 
information to its PDP engine 260 for updating its kernel 265 with the latest changes. 

Although FIG. 15 has been described in connection with addition of a route to a policy 
enforcer and its associated VPNs, it should be readily apparent to those skilled in the art that 

35 essentially the same techniques may be applied to deletion of a route<for example, if a network 
component becomes inoperative or incommunicative), orchange of a route (the policy router may 
recognize that a route already exists in a different form and simply overwrite it). In this way, the 
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1 VPN system or sysiems can dynamically maintain routing information between its policy 

enforcers with minimal intervention by the system administrator. 

V. VIRTUAL PRIVATE NETWORK HAVING AUTOMATIC UPDATING OF 
. CLIENT REACHABILITY INFORMATION 

Remoie u:>ers communicate over the public Internet 108 with the other members of the 
VPN behind policy enforcers 124, 126,' upon presenting appropriate credentials. These remote 
. users access the private networks as VPN clients 140 using a VPN client software. According to 
one embodiment of the invention, the system allows the remote user to download a self- 
10 cxlraciing executable which, upon execution, installs both the VPN client software and VPN 
reachability information unique to the remote user in the user's remote terminal. 

Each policy enforcer 124, 126 preferably maintains a copy of the self-extracting 
exccuuble of ihc VPN client software including a setup program and VPN reachability 
confiyuraiion icmplaic. The setup program allows the VPN client software to be installed on the 
15 VPN clicni 140. When downloading the self-extracting executable, the configuration template 
is replaced with the VPN reachability information that is specific to the downloading user. 

According lo another embodiment of the invention, the system allows the VPN client 140 
to download a self-extracting executable which, upon execution, only installs the VPN 
reachability informaiion that is unique to the user. According to this embodiment, the VPN client 
20 software is already installed on the VPN client 140. In this scenario, the setup program allows 
the installation of the reachability information that is specific to the downloading user, on the 
VPN client 140. 

According to a third embodiment of the invention, the system allows the VPN client 140 
to automatically download the VPN reachability information each time it connects to the policy 

25 enforcer 124, 126. Thus, VPN reachability information is kept up-to-date for each VPN client 
140. Once a VPN session is established, the connection between the VPN client 140 and the 
policy enforcer is assumed to already be secure. The VPN client preferably makes a common 
gateway interface (CGI) query to a web server running on the policy enforcer, and downloads the 
current VPN reachability information from the corresponding LDAP database. 

30 FIG. 1 6 is a block diagram of components in a self-extracting executable 290 according 

to one embodiment of the invention. The self-extracting executable 290 may be created using 
commercially available tools such as the INSTALLSHIELD EXEBUILDER of InstallShiled 
Software Corporation of Schaimiburg, Illinois. 

The self-extracting executable 290 preferably includes an executable setup file 292 for 

35 installing the VPN client software and/or the VPN configuration information. The setup file 292 
preferably forms a static portion 298 of the self-extracting executable since this information does 
not change based on the downloading VPN client. The self-extracting executable 290 ftirther 
includes VPN configuration file templates for the VPN reachability information 294 and the VPN 
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1 client's preshared key informaiion 296. The VPN reachability information 294 and the VPN 

client's preshared key 296 preferably form a dynamic portion 299 of the self-extracting 
executable 290 since this information changes based on the downloading VPN client. The self- 
extracting executable 290 is then saved as a template file in the policy enforc-ers 124, 126 and is 

5 ready to the downloaded by the remote users. 

FIG. 1 7 is a functional block diagram for downloading the self-extracting executable 290 
of FIG. 16 according to one embodiment of the invention. In step 320, a new VPN client 140 
first establishes a secure communication session with the policy enforcer 124, 126 to download 
the self-extracting executable 290. Preferably, this is accomplished via an HTTPS protocol 

10 session on the VPN client's web browser or the like. In steps 322 and 324, the policy enforcer 
engages the VPN client in an authentication procedure where the policy enforcer requests, and 
the VPN client provides, his or her user name and password. In step 326, the policy enforcer 
compares the provided information with entries in its VPN client database 328. If the 
information is correct, the policy enforcer finds appropriate preshared keys for the user, and in 

15 step 330, also determines the VPN reachability information of tlie client from a VPN 
configuration database 332. The VPN client database 328 and VPN configuration database 332 
may reside as part oJ a single LDAP database 312, 3 14 managed by the policy -enforcer 124, 1 26, 
or may constitute separate LDAP databases. 

In step 334, the policy enforcer replaces the dynamic portion 299 of the self-exU-acting 

20 executable 290 with the VPN reachability information and preshared key that is unique to the 
VPN client. The newly generated self-extracting executable is then downloaded to the VPN 
client 140 in step 336. When the executable is run, it either installs the VPN client software 
and/or the VPN reachability information. 

Similar techniques may also be used for downloading a new and updated copy of the VPN 

25 configuration information to the VPN client each time the client connects to the policy enforcer 
and negotiates a session key. In addition, the user may obtain the latestconfiguration of the VPN 
network by expressly requesting the policy enforcer for such information. Thus, the VPN client 
need not be reinstalled and reconfigured each time updates are made to the VPN reachability 
information. 

30 

VI. INTEGATED POLICY ENFORCER 

According to one embodiment of the invention, the functionalities of the policy enforcer 
124, 126 for policy enforcement are partitioned for effective hardware implementation. 
However, it should be apparent to one skilled in the art that some or all of the fimctionalities may 
be implemented in software, hardware, or various combinations thereof. 

FIG. 18 is a schematic block diagram of the policy enforcer 124, 126 illustrating the 
partitioning of the various functionalities according to one embodiment of the invention. The 
policy enforcer includes an Internet protocol security (IPSec) engine 502 for performing security 
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1 and authentication functions in implement ing, for instance, virtual private networks. A stream 

table 506 assembles the packets passing through the policy enforcer into streams. A protocol 
classification engine 508 decodes the protocols used in forwarding the packets. A policy engine 
510 enforces policies for the packets based on the policy settings stored in the policy database 
5 132, 134. A packet forwarding module 504 receives packets from the public Internet via the 

router 110 and buffers, forwards, or drops the packets based on the policies being enforced. A 
bandwidth management module 514 provides bandwidth shaping services to the packets being 
• forwarded based on the bandwidth settings stored in the policy database 132. 134. 

In practice, an incoming packet is matched against the stream table 506 Tor determining 
10 if a matching entry already exists in the table. If not, a new entry is added. The stream table 
preferably includes enough portions of the packet to uniquely identify a stream. For example, 
in enforcing policies on IP layer three through layer four traffic, the stream table may store a 
source IP, destination IP, source port, destination port, and protocol number of the incoming 
packet. 

15 The protocol classification engine 508 takes the new stream and obtains a detailed 

protocol decode for the stream. The policy engine 510 is then queried for the policy rules to be 
applied to the stream. Based on the policy rules returned by the policy engine 510, the packet 
forwarding module 504, IPSec engine 502, and/or the bandwidth management module 514 
process the streams accordingly. The processing may be recursive until the packets in the stream 

20 have had all the actions specified by the policy rule set applied to them. 

The policy enforcer also includes a statistics module 512 for collecting statistics on the 
packets forwarded through the local network as well as other status and resource usage 
information, and provides the same in logs and archives for sending to the policy server 122. 
According to one embodiment of the invention, the statistics module 512 keeps running byte 

25 counts of the packets passing through the network 102, 104. These byte counts may be 
automatically sorted by classes, such as classes based on certain resources (e.g. users, hosts, 
services), as well as by bytes that are blocked by policies and exceptions, such as firewall 
policies. In this regard, the statistics module 512 maintains in a cache a state table including a 
list of resources involved for each connection allowed through the firewall. For every packet 

30 flowing through the connection, the statistics module increments the packet and byte cotint for 
each of the resources in the list. The statistics module 512 then forwards the organized 
information to the policy server 122 which enters the infomiation directly into tables organized 
by classes and aged out periodically. 

FIG. 19 is a more detailed schematic block diagram of the policy engine 510 according 

35 to one embodiment of the invention. The policy engine 5 1 0 includes a policy request table 602 
that acts as a queue for all the policy decision requests. In this regard, the portion of the packet 
matching the information stored in the stream table 506 is presented to the policy engine 5 1 0 in 
the form of a policy request. The policy request is then queued in the policy request table 602. 
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1 A resource engine 604 maintains , an up-io-tJate mapping of resource ^group nances to 

member mappings. A policy rules database buffer 608 stores a current policy rule set to be 
applied by the policy engine 510, The policy rules stor-ed in the buffer 608 are preferably in the 
original group-based rule specification format. Thus, the buffer 608 stores a rule created for a 

5 sroup in its group-based form instead of instantiating a rule for each member of the group. 

A decision engine 606 includes logic to serve the incoming policy decision requests in 
the policy request table 602 by matching it against the policy rule set in the policy rules database 
buffer 608 based on the actual membership information obtained from the r«source^nginei604. 
The relevant group-based rule matching the traffic is then identified and decision bits in the 

1 0 stream table set for enforcing the corresponding actions. The decision bits thus constitute the set 
of actions to be performed on the packets of die stream. All packets matching the streams are 
then processed based on these decision bits. The decision engine may also specify an access 
control list <ACL) including a set of rules that allow/deny traffic, a DifTServ standard for 
providing a quality of service level to the traffic, and/or VPN implementation information. 

15 FIG. 20 is a more detailed schematic block diagram of the protocol classification engine 

508 according to one embodiment of the invention. As illustrated in FIG. 20, the protocol 
classification engine 508 includes a stream data assembly 702, a sliding stream data window 704, 
an ASN.l block 706, a protocol classification state machine 708, and a protocol definition 
signature database 7 1 0, The stream data assembly 702 exuracts and re-assembles the data portion 

20 of an input packet stream and stores it in the sliding stream data window 704. Preferably, the 
sliding stream data window follows first-in- first-out protocols. The ASN.l decoder further 
decodes the data stream, if needed, per conventional ASN.l encoding/decoding standards. The 
protocol classification state machine 708 then matches the fully re-assembled and decoded data 
against the protocol definition signature database 710. This database 710 preferably holds a 

25 mapping of protocol names to data patterns to be found in the data stream. The matched protocol 
is then returned to the stream table 506. 

Thus, the protocol classification engine 508 provides extensive layer thr-ee through layer 
seven protocol decode and packet classification, including complete identification of dynamic 
streams using a dynamically updated signature database compiled from scripted protocol 

30 definitions. As new protocols are defined in the future and/or users create their own custom 
applications with custom protocols, a need may arise to add recognition of these protocols to the 
protocol classification engine. The described protocol classification engine architecture allows 
such additions by simply adding a new scripted definition of the new protocol to the protocol 
classification engine without having to change the design each time a new protocol is added. 

35 This allows for custom protocol support and future protocol extensibility. 

FIG. 21 is a more detailed schematic block diagram of the IPSec engine 502 according 
to one embodiment of the invention. As illustrated in FIG. 21, the IPSec engine 502 includes a 
Pseudo-Random Number Generator (PRNG) function 802 for generating random numbers used 
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1 for cryptographic key generation according to well knoun methods. A Diffie Hellman 804 and 

RSA 812 blocks implement the corresponding asymmetric public key 
■ encryption/decryption/signature algorithms which are also well known in the art. An IKE block 
806 communicates with an IPSec S A table 808 for implementing standard ISAKMP/Oakley(IKE) 
5 key exchange protocols. A cryptographic transforms block 8 1 4 implements standard symmetric 

encryption/decryption algorithms. An IPSec Encapsulation/Decapsulation block 810 performs 
standard encapsulation/decapsulation functions. Accordingly, the IPSec engine 502 provides 
• mature, standards-based IKE/IPSec implementation with public key certificate support and 
necessar}' encryption/decr>'ption functionality for packets passing through the private local 
1(1 networks 102, 104. 

VII. NETWORK POLICY LOGS AND STATISTICS AGGREGATION 

Referring again to FIG. 3, the log collecting and archiving module 304 collects 
information about the status and usage of resources from the policy enforcers 124, 126 as well 
as from the management module 302, and stores them in the archive database 318. The policy 
scr\'cr reports module 316 then uses the collected logs and archives to generate reports in an 
organized report format. 

According to one embodiment of the invention, each policy enforcer 1 24, 126 maintains 
a log file with information collected about the flow of traffic through the policy enforcer as well 
as the status and usage of resources associated with the policy enforcer. All the log files follow 
a predefined common log format, preferably designed to create compact logs. 

FIG. 22 is a schematic layout diagram of such a log format according to one embodiment 
of the invention. Each log entry includes a timestamp 820 in the format yyyymmddhhmmss, 
indicative of the year, month, date, hours, minutes, and seconds in which the log entry was 
created. A service field 822 indicates the type of service rendered by the policy enforcer 124, 
126. Such services include VPN, FTP, Telnet, HTTP, packet filter, bandwidth, and the like. 
Each log entry further includes a source IP address and port 824 indicating the source from where 
a packet was received, as well as a destination IP address and port 826 indicating the destination 
to which the packet was forwarded. 
30 A user ID field 828 identifies the user transmitting the packet. The user ID may be 

mapped to an entry in the LDAP database 130, 132, or 134 for obtaining additional details about 
the user. 

A status field 830 indicates the status of an operation and may include a result code, error 
code, and the like. For example, for a packet filter service, the status field may include a result 
3^ code "p'' if the packet was passed or code "b" if the packet was blocked. 

An operation field 832 indicates codes for a type of operation conducted by the service. 
For instance, operations for a VPN service may include sending packets and receiving packets. 
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1 Operations for an FTP service may indude GET and PUT operations. Operations for an HTTP 
service may include GET and POST operations. 

In addition to the above, each log entry includes an in-bytes field 832 indicative of the 
number of bytes the policy enforcer received as a result of the activity, and an out-bytes field 834 
5 indicative of the number of bytes transferred from the policy enforcer. Furthermore, a duration 
field 836 indicates the duration (e.g. in seconds) of the activity. 

Certain fields of a particular log entry may be left blank if not applicable to a particular 
service. For instance, for an FTP dovmload. Where there is no outgoing traffic, the out-bytes 
field is left blank. Furthermore, additional fields may be added based on the type of service being 
10 logged. For instance, for an HTTP activity, the URL that is accessed is also logged in the log 
entry. The additional fields are preferably appended to the end of the standard log format. 

A person skilled in the art should recognize that additions, deletions, and other types of 
modifications may be made to the log format v^dthoul departing from the spirit and the scope of 
the invention as long as the log format common to all the policy enforcers and is aimed in 
15 creating compact logs. 

The log files created by the policy enforcers 124, 126 are transferred to the policy server 
122 based on archive options set by Uie policy server. In this regard, the network administrator 
specifies a threshold size for the logs created by the policy enforcers upon selection of the policy 
server archive option 752 of FIG. 9. When the log file exceeds the specified size, it is sent to the 
20 policy server 1 22. Preferably, the logs are transferred to the policy server 1 22 at least once a day 
even if the threshold size has not been exceeded. The logs may also be archived locally at the 
policy enforcer if so specified by the network administrator. 

Once ihe policy server 122 receives the logs, it is stored in the archive database 318 
preferably taking the form of an SQL database. The policy server reports module 3 1 6 queries this 
25 database to generate reports for each policy enforcer 124, 126. In addition, the logs may be 
exported in a format that may be, interpreted by commercially available products such as 
WEBTRENDS, manufactured by WebTrends Corporation of Portland, Oregon. 

The reports created by the reports module 316 include summary usage reports for the 
various resources including policy enforcers, users, services, hosts, and VPNs. For instance, the 
30 reportsmay include VPN summary reports, bandwidth summary reports, packet filter reports, and 
the like, for each policy enforcer. 

The reports preferably show usage of each of the resources over a period time. The start 
and the end date for the report may be specified by the user. The user may ftirther drill down on 
the time dimension and on the resource dimension for viewing ^cific times and specific 
35 resources. For instance, in creating the packet filter reports, the user may indicate a start and end 
time, source IP address, source port, destination IP address, and destination port. All packets 
meeting these criteria are then fetched from the archive database 318 and shown in a packet 
report. 
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^ VIII. METHOD FOR SELECTIVE LDAP DATABASE SYNCHRONIZATION 

According to one embodiment of the invention, the databases 1 30, 1 32, 1 34 in the unified 
policy management system of FIG. 1 are LDAP databases storing policy management 

5 information including policies for firewall. VPNs, bandwidth, administration, user records, 

network records, services, and the like. As described above, the LDAP directory service model 
is based on entries where each entry is a collection of attributes. Entries are arranged in a tree 
. structure that follows a geographical and organizational distribution. Entries are named 
according to their position in the hierarchy by a distinguished name (DN). 

10 The policy server 122 preferably stores the policy management information for all the 

policy enforcers in the policy server database 1 30. This information is organized in the databases 
1 30 as one or more DNs with corresponding attributes. Appropriate portions of the policy server 
database are then copied to the policy enforcer databases 132. 134. 

FIG. 23 is a block diagram of an LDAP tree structure including an LDAP root 265 and 

15 a plurality of branches 264, 266, 268, 270. According to one example, the policy server 122 
maintains in the policy server database 130 branches 264 and 266 with policy management 
information for all the policy enforcers 124, 126. Each of the policy enforcers 124, 126 also 
maintain portions of the branches 264 and/or 266 in their respective policy enforcer databases 
1 32, 1 34 as sub-trees of the policy server database 1 30. The portions of the branches maintained 

20 by each policy enforcer 124, 126 preferably relates to the configuration information for that 
policy enforcer as well as some additional information about the other policy enforcers. This 
additional information is used to communicate with the other policy enforcers. 

The policy server 1 22 may further maintain branch 268 storing informiation used only by 
the applications ruiuiing on the server and not shared with any of the policy enforcers 124, 126. 

25 Likewise, policy enforcers 1 24, 1 26 may maintain a portion of branch 268 containing information 
used only by the applications on each of the policy enforcers and not shared elsewhere. 
Typically, the data stored in branch 268 is dynamically generated and used by the applications 
running on the corresponding server or agent. 

Branch 270 is preferably only included in the LDAP tree for the policy server database 

30 130 and stores logged policy management changes that may be propagated to the policy enforcers 
1 24, 1 26. Such changes may include, for example, addition, deletion, or modifications of a user 
on a device, VPN cloud, bandwidth policy, or firewall policy made by the network administrator 
via the various graphical user interfaces described above. Such changes result in the updating 
of the policy database 130 where the corresponding DN of the LDAP tree is added, deleted, or 

35 modified. The policy server 122 further creates a log of the changes and stores them in branch 
270 for later distribution to the policy enforcers 124, 126. 

FIG. 24 is a more detailed block diagram of branch 270 of the LDAP tree of FIG. 23. The 
LDAP root 265 includes an ApplyLog 270a entry which in turn includes a user log entry 270b 
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1 and a device log entry 270c. The user log entries include specific administrator log entries 

identified by specific DNs 270d for reflecting the changes made by the particular administrators. 

The device log entry 270c includes specific device log entries identified by specific DNs 270e 

reflecting the changes that are to be distributed to the particular policy enforces 124, 126. 
5 Preferably, the changes made by the administrators are propagated to the policy enforcers 124, 

126 upon actuation of an apply button such as the apply button 417 illustrated in FIG- 6. 

FIG. 25 is a flow diagram for logging and propagating LDAP changes to the policy 

enforcers according to one embodiment of the invention. In step 420, a particular network 

administrator makes a policy setting change. According to one example, the administrator is 
10 administrator "adm'' working in the domain "domain 1 and the change is the addition of a new 

user on a device. 

In step 422, the change made the administrator is reflected in the policy server database 
130. In this regard, branches 264 and 266 of the LDAP tree are modified accordingly to reflect 
the change in the policy setting. Additionally, in step 424, the policy server 122 creates a log of 

1 5 the changes for the administrator for later processing and sending to the appropriate policy agent. 
In step 426, the policy server 122 updates the administrator's log DN 270d to reflect the change. 
In the above example and as illustrated in FIG. 24, if the log created is named "A_L1 the policy 
server 122 updates the DN 270d for ^"adm" at "domainl " to create an attribute "apply" 270f that 
has the value ''A_L 1 270g. Other changes made by the administrator are reflected in separate 

20 logs (e.g. "A_L2," "A_L3") and appended to the existing value of the apply attribute in the 
administrator's log DN 270d. 

In step 428, the policy server 122 checks whether the changes made by the administrator 
are to be propagated to the appropriate policy enforcers 124, 126. As discussed above, the 
changes are preferably propagated upon actuation of an apply button from the administrator's 

25 graphical user interface. 

If the apply button has been actuated, the policy server creates, in step 430, a log for each 
policy enforcer to wliom the change is to be transmitted. In this regard, the policy server 122 
collects all the changes made by the administrator as reflected in the values 270g, 270h of the 
apply attribute 270f of the administrator's log DN 270d. These changes are processed for each 

30 policy enforcer belonging to the administrator's domain. Such processing preferably involves 
picking the relevant changes and suitably modifying the DNs for the policy enforcer's LDAP. 
Such suitable modifications may be necessary, for instance, due to the differences in the tree 
structures in the policy server database 130 and the policy enforcer databases 132, 134. For 
instance, a change in the administrator's log may contain a DN that specifies the domain name 

35 of the policy enforcer. In applying this change to the policy enforcer, the domain name would 
not be specified in the DN since the policy enforcer's tree structure does not include a domain 
name. 
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1 The changes suitably modified lor -each policy enforcer's LDAP are then stored in a 

device log. Each policy enforcer s log DN 270e is then modified to reflect the change to the 
transmitted to the particular policy enforcer. In the above example and as illustrated in FIG. 24, 
if the device log created is named "PE_L1 /' the policy server 122 updates the DN 270e for the 

5 particular policy enforcer "PEl " at "domainl " to create an attribute "apply" 270i that has the 

value "PE.LllZTOj.. . . 

In step 432, the apply attribute 2'70f for the administrator's log DN 270d is then deleted 
. from the LDAP tree. In step 434, the changes collected for-each policy enforcer, as reflected in 
the values 270j, 270k of the apply attribute 270i of the policy enforcer's log DN 270e, are 

1 0 transmitted to the policy enforcer for updating its database 1 32, 1 34. The changes are sent to the 
policy enforcers preferably over the HTTPS channel. 

In step 436, the policy server 122 checks whether the updates have been successful. In 
this regard, the policy server 122 waits to receive an acknowledgment from the policy enforcer 
that the updates have been successfully completed. Upon a positive response from the policy 

15 enforcer, the policy server 1 22 deletes the apply atu-ibute 270e for the policy enforcer's log DN 
270e. Otherwise, if the update was not successful (e.g. because the policy enforcer was down), 
the apply log is re-sent the next time another apply function is invoked. Alternatively, the failed 
policy enforcer transmits a request to the policy server 122 of the log of non-applied changes 
when it rejoins the network (e.g. by rebooting). 

20 

IX. STATE TRANSITION PROTOCOL FOR HIGH AVAILABILITY UNITS 

According to one embodiment of the invention, the policy server 122, policy enforcers 
1 24, 1 26, as well as other network devices may be configured for high availability by maintaining 
a backup unit in addition to a primary unit. 
25 PIG 26 is a schematic block diagram of a high availability system including a primary 

unit 902 and a backup unit 904. The two units 902, 904 communicate with each other by 
exchanging heartbeats over parallel ports 906a, 906b and a cable 908. Such parallel ports 906a. 
906b and cable 908 are conventional components that are commonly available in the art. 

The primary unit 902 and the backup unit 904 are each similarly connected to other 
3^ components 9 1 0, 9 1 2, 9 1 4 via ports 920a, 920b, 922a, 922b, 924a, 924b, respectively. These 
components 910, 912, 914 may be hubs, switches, connectors, or the like. Because the primary 
unit 902 and backup unit 904 provide similar services and functions and may be used 
interchangeably, each unit is preferably connected to the same components 910, 912, 914. 

The parallel port cable 908 is preferably a conventional laplink cable designed to connect 
two parallel ports and allow communications between them. The primary imit 902 and the 
backup unit 904 preferably communicate with each other via TCP packets over the high- 
availability ports 906a, 906b. A point-to-point connection preferably exists between the primary 
unit 902 and the backup unit 904 over the high-availability ports 906a, 906b. 
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1 The primary unit 902 is preferably responsible for checking the status of its network ports 

for problems or failures. For example, if the primary unit 902 detects that one of its network 
pc'rts is inoperable, e.g. port 922a, the primary unit 902 then-checks whether the -corresponding 
port 922b in the backup unit 904 is operational. Upon determining that the corresponding port 
5 922b in the backup unit 904 is operational, the primary unit 902 sends a request to the backup 
unit 904 to take over the system functions as the active unit. The primary unit 902 then 
relinquishes its role as the active unit and shuts itself down, allowing the backup unit 904 to take 
on the responsibilities of the primary unit 902. When the primary unit 902 restarts operation, the 
backup unit 904 receives a request from the primary unit 902 to relinquish its role as the active 
10 unit. 

When the primary unit 902 is active and does not detect any defects in its ports, it 
continuously listens on the high-availability port 906a to keep track of the status of the backup 
unit 904. The primary unit 902 continues to listen on the high-availability port 906a for signals 
coming from the backup unit 904. When the backup unit 904 is up and running, it connects to 

15 the primary unit 902 Once the connection is made, the backup unit 904 begins sending 
heartbeats to the primary unit 902. The backup unit 904 continuously sends heartbeats to the 
primary unit 902 in predetermined intervals. According to one embodiment of the invention, the 
backup unit 904 sends a "Keep Alive" packet including a KEEP_ALIVE command to the 
primary unit 902 every one second. 

20 The primary unit 902 responds to the "Keep Alive" packet by changing thecommand field 

of the packet to a KEEP_ALIVE_RESP command and re-transmitting the packet to the sender. 
If the backup unit 904 does not receive a response back from the primary unit 902 for a 
predetermined period of time (e.g. one second) for one "Keep Alive" packet, the backup unit 904 
begins preparing to take over the active role. Preferably, the predetemiined period should not be 

25 greater less than two consecutive "Keep Al'we" packets. 

Upon taking the role of the active unit, the backup unit 904 attempts to reestablish a 
connection with the primary unit 902 at regular intervals to detennine whether the problem or 
failure in the primary unit has been cured. If the problem or failure has been cured, the backup 
unit 904 relinquishes its conttol to the primary unit 902 after setting the IP addresses of all the 

30 network interface cards to the assigned value. 

In situations where the backup unit 904 takes over the active role from the primary unit 
902, an alert/alann is sent to the network adminisu-ator indicating such a change. In addition, if 
the primary unit 902 does not receive heartbeats from the backup unit 904, an alert/alarm is sent 
to the administrator indicating that the backup imit has failed. 

35 A situation may arise when both the primary unit 902 and the backup unit 904 are fully 

functional, and the backup unit 904 desires to take over the active role. In ihis-case. the backup 
unit 904 transmits a shut-down command to the primary unit 902 which then relinquishescontrol. 
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1 The backup unit 904 continues its role as the active unit until the primary unit 902 transmits a 

request to the backup unit 904 to relinquish its active role. 

According to one embodiment of the invention, the initial status determination protocol 

of each high availability unit as a primary, backup, or stand-alone unit relies on a self-discovery 
5 process. FIG. 27 is a flow diagram of an exemplary status discovery process according to one 

embodiment of the invention. In step 930, a first high availability unit (unit X) that has not yet 

definitively discovered its status as a primary or a backup unit boots up, and in step 932 assumes 
. the role of a backup unit. In step 934, unit X searches the network for a primary unit and 

inquires, in step 936. whether a primary unit has been detected. If the answer is YES, unit X tries 
10 to connect to the primary unit. If it is successful, unit X initializes as the backup unit in step 938. 

If, on the other hand, unit X does not detect the primary unit, unit X assumes the role of the 

primary unit in step 940. 

In step 942, unit X searches the network for a backup unit. If the backup unit is detected, 

as inquired in step 944, unit X connects to the backup unit and initializes as the primary unit in 
15 step 946. If, on the other hand, unit X does not detect any other units in the network within a 

predetermined time, unit X initializes as a stand-alone unit in step 948. 

Once the primary and secondary units have been initial!^, configuration changes of the 

primary unit are also transferred to the backup unit in order to keep the two units synchronized. 

The configuration information is preferably stored in an LDAP database such as thecentral policy 
20 server database 130 or policy agent databases 124, 126. 

FIG. 28 is a flow diagram of a process for maintaining configuration information 

synchronized in the primary and backup units. In step 950, the primary unit boots up and in step 

952, detects the backup unit. In step 954, the backup unit receives configuration change 

information from the primary unit if it is functional. Otherwise, the configuration changes are 
25 entered directly into the backup unit by the network administrator. If the configuration change 

is to be received from the primary unit, the primary unit notifies the backup unit when 

configuration changes occur in the primary unit. The changes are then transferred and applied 

to the backup unit. The backup unit in turn transmits the status of the transfer and the apply back 

to the primary unit. 

30 In step 956, the primary unit is checked to deteraiine whether it is functional. If it is, the 

primary unit is likewise updated with the configuration change. Otherwise, if the primary unit 
is not functional, the backup unit takes on the active role and becomes the active unit in step 958. 
The primary unit may become non-functional and thus, inactive, due failures in the CPU board, 
the network interface card, or power supply. 

35 In step 960, the backup unit tags the changes to transfer them to the primary once the 

primary becomes functional. Once the primary unit becomes functional, the primary unit is 
updated with the tagged changes maintained by the backup unit as is reflected in step 962. 
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1 According to one embodiment of the invention, software updates on the primary and 

backup units are also synchronized so as to update the primary and backup units -serially in a 
single cycle without the need for multiple update cycles. Thus, the network administrator need 
not duplicate the efforts of updating the backup unit with the same information as the primary 
5 unit. 

- FIG. 29 is an exemplary flow diagram of updating the primary and backup units when 
they are both functional. In step 970, an update, such as a software update not stored in the 
LDAP databases, is sent/transmined to the primary unit from a management station accessible 
by the network administrator. The primary unit then updates itself in step 972. In step 974, the 

10 primary unit automatically sends/transmits the update information io the backup unit. In step 
976, the backup unit updates itself with the update information received from the primary unit. 

FIG. 30 is an exemplary flow diagram of updating the primary and backup units when the 
primary unit is not functional. In step 978, the primary unit becomes nonfunctional, and in step 
980, the network administrator sends/transmits an upgrade directly to the backup unit instead of 

15 the primary unit. In step 982, the backup unit updates itself with the information received from 
the management station and waits for the primary unit to become functional. Once the primary 
unit becomes functional, the update is automatically sent/transmitted to the primary unit for 
upgrading in step 986. The primary unit then updates itself in step 988, 

Although the present invention has been described in detail v^th reference to the preferred 

20 embodiments thereof, those skilled in the art will appreciate that various substitutions and 
modifications can be made to the examples described herein while remaining within the spirit 
and scope of the invention as defined in the appended claims. 

For example, the unified policy management system of FIG. I should be viewed as 
illustrative rather than limiting. It should be apparent to those skilled in the art who are 

25 enlightened by the present invention that many alternative configurations are possible. For 
example, there may be additional networks with policy enforcers or no additional networks at all. 
Likewise, policy enforcers may not necessarily access the policy server through the Internet, but 
may be connected via other means such as a WAN, MAN, etc. In short, the number and type of 
users and resources within and without the organization can vary greatly while staying within the 

30 scope of the invention. 



35 
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1 CLAIMS: 

1. A system for managing policy services in an organization, the organization 
including a first network having a first set of resources and a second network remote from the 
first network having a second set of resources, the system comprising: 

5 a first edge device associated with the first network, the first edge device configured to manage 
poHcies for the first network and the first set of resources in accordance with first policy settings 
stored in a first database; ' 
, a second edge device associated with the second network, the second edge device configured to 
manage policies for the second network and the second set of resources in accordance with 

10 second policy settings stored in a second database; and 

a central policy server in communication with the first and second edge devices, the central 
policy server configured to define the first and second policy settings and manage the first and 
second cduc devices from a single location. 

1 5 2. The system of claim 1 , wherein the policies are firewall policies. 

3. The system of claim 1 , wherein the policies are virtual private network policies. 

4. The system of claim 1 , wherein the central policy server includes a central database 
20 for storing configuration information of the first and second edge devices. 

5 . The system of claim 4, wherein the configuration information includes the first and 
second policy seuings. 

25 6. The system of claim 4, wherein the central database stores a log of changes in the 

configuration information for the first and second edge devices. 

7. The system of claim 6, wherein the policy server transmits the changes in the 
configuration information to the first and second edge devices for respectively updating the first 
and second databases. 

30 

8. The system of claim 7, wherein the policy server deletes the log of changes upon 
a successful update of the first and second databases. 

9. The system of claim 4, wherein the cenU-al database and the first and second 
35 databases are organized according to a hierarchical object oriented structure. 

1 0. The system of claim 9, wherein the hierarchical object oriented structure includes 
a plurality of resource objects and policy objects for defining the first and second policy settings. 
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1 11. The system of claim 10, \\4ierein the resource objects are^lected from a^roi^consisting 

of devices, users, hosts, services, and time, 

12. The system of claim 10, wherein the central database and the first and second 
5 databases are Lightweight Directory Access Protocol (LDAP) databases storing -each resource 

object and policy object as an LDAP entry. 

13. The system of claim K wherein the central policy server includes a set of user 
application modules for allowing a user todefine the first and second policy settings and manage 

10 the first and second edge devices from the single location, the first and second policy settings 
being associated with a plurality of resource objects including devices, users, hosts, services, and 
time. 

14. The system of claim 13, wherein the set of user application modules includes a 
centralized management sub-module for allowing installation of the first and second edge devices 

15 from the single location. 

1 5. The system of claim 14, wherein the centralized man^ement sub-module allows 
registration of the first and second devices with the central policy server. 

20 16. The system of claim 13, wherein the set of user application modules includes a 

policy management sub-module for managing and viewing the resource objects from the single 
location. 

17. The system of claim 1, wherein the central policy server includes a set of user 
25 application modules for allowing a user to monitor health and status of the first and second edge 

devices from the single location. 

1 8. The system of claim 1 , wherein the central policy server includes: 

a log collecting and archiving module for periodically receiving health and status 
30 information from each of the edge devices; 

an archive database coupled to the log collecting and archiving module for storing the 
health and status information; and 

a reports module coupled to the archive database for creating reports based on the health 
and status information. 



35 



1 9, The system of claim 1 8, wherein each edge device collects and transmits health and 
status information in a predefined common log format. 
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20. The system of claim 1 8, wherein the health and status information includes network 
flow information. 

21. The system of claim 18, wherein the health and status information includes 
statistics on use of each edge device's set of resources. 

22. The system of claim 1 , wherein each edge device includes a plurality of modules 
for integrating management of the policies for each of the networks into the edge device. 

23. The system of claim 22. wherein the plurality of modules include: 

a classification engine for determining a protocol associated with an incoming packet; 
a policy engine for making a forwarding decision for the packet based on policy settings 
associated with the packet; and 

a packet forwarding module for forwarding the packet based oh the policy settings, 

24 . The system of claim 23 forther including a security engine for authenticating a user 
transmining the packet. 



25 . The system of claim 23 further including a statistics module for collecting statistics 
20 on packets flowing through the edge device. 

26. The system of claim 1 , wherein each network is a private network and each edge 
device is configured to create a table with information of member networks reachable through 
the edge device. 



27. The system of claim 26, wherein the first and second edge devices enable secure 
communication between the first and second private networks, and the first edge device shares 
the first table with the second edge device and the second edge device sharing the second table 
with the first edge device. 

28. The system of claim 26, wherein the first edge device includes logic for: 
receiving a new route information; 

storing the new route information in the first database: and 

transmitting a portion of the new route information to the second edge device. 

29. The system of claim 26, wherein the conunvmication is managed according to a 
security policy associated with the member networks. 
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30. The system of claim 29, wherein the security policy is defined for a^ecurity policy 
group providing a hierarchical organization of the group, the group including member networks, 
users allowed to access the member networks, and a rule controlling access to the member 
networks. 

._.31. ----The s>:stem-of claim 30,-wherein.each.member network has full connectivity with 
all other member networks and the security policy defined for the security policy group is 
automatically configured for each connection. 

32. The system of claim 30, wherein the security policy provides encryption of traffic 
among the member networks and the rule is a firewall rule providing access control of the 
encr> pied traffic among the member networks. 

33. The s\ siem of claim 30 further including remote user terminals for accessing the 
incinhci nci\M»ik^ I'orin a remole location, each remote user terminal including a processor, the 
processor being operable to execute program instructions, the program instructions including: 

establishing communication with the edge device; 
transmitting authentication information to the edge device; and 

receiving the table with the information of the member networks from the edge device. 

34. The system of claim 33, wherein the program instructions further include 
automatically receiving updates of the table from the edge device. 

35. The system of claim 1 , wherein the central policy server and the first and second 
25 edge devices include first class units and second class units, each second class imit providing 

backup for a corresponding first class unit upon failure of the first class unit. 

36. The system of claim 35, wherein each of the second class units is initially in an 
inactive state, each of the second class units including logic for: 

30 delecting a failure of its corresponding first class unit; and 

transitioning from the inactive state to an active state upon detection of the failure. 

37. The system of claim 35, wherein each of the second class units includes logic for: 
assuming a role of the second class unit; 

35 searching for the corresponding first class unit; and 

initializing as the second class unit if the corresponding first class unit is detected. 



20 



-34- 



ff«ISOOCIO: <WO,__<»78004A2_L> 



wo 00/78004 PCTAJSOO/1 6246 

1 38. 'I'he system of claim 37, wherein each of the second class units further includes 

logic for: 

assuming a role of the first class unit if the first class unit is not detected; 
searching for a corresponding second class unit; and 
5 initializing as the first class unit if the corresponding second class unit is detected. 

39. The system of claim 38, wherein each of the second class vmits further includes 
• logic for initializing as a third class unit if the corresponding second class unit is not detected. 

10 

40. The system of claim 35 further comprising: 

means for transitioning each of the first class imits to an active state; 
means for receiving and storing first database configuration changes for each of the first 
class units; 

1 5 means for transferring the configuration changes to the corresponding secondclass units; 



and 



means for storing the configuration changes on the corresponding second class units. 



41. The system of claim 40 further comprising: 

20 means for transitioning each of the first class units to an inactive state; 

means for receiving and storing second database configuration changes for the second 
class unit while the corresponding first class unit is in the inactive state; and 

means for transferring the second database configuration changes from the second class 
unit to the first class unit after the first class unit re-transitions to the active state. 

25 

42. The system of claim 35 fiirther comprising: 

means for transmitting update information to each of the first class units: 
means for updating each of the first class units; 

means for transmitting the update information from each of the first class units to each 
30 of the second class units; and 

means for updating each of the second class units. 

43. A system for managing policy services in an organization, the organization 
including a first network having a first set of resources and a second network remote from the 

35 first network having a second set of resources, the system comprising: 

a first edge device associated with the first network, the first edge deviceconfigured 
to manage policies for the first network and the first set of resources in accordance with first 
policy settings stored in a first database; 
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1 a second ^dge device associated with the second neivvork, the second edge device 

configured to manage policies for the second network and the second set of Fesources in 
accordance with second pohcy settings stored in a second database; and 

a central policy server defining the first and second policy settings and managing 

5 the first and second edge devices from a single location, thecentral policy server being associated 
with a central database storing configuration information of the first and second edge devices, 
wherein the central database is organized according to a hierarchical object oriented structure. 

44. The system of claim 43, wherein the first and second databases are organized 
10 according to the hierarchical object oriented structure. 

45. The system of claim 43, wherein the configuration infomiation includes the first 
and second policy settings. 

1 5 46. The system of claim 45, wherein the hierarchical object oriented structure includes 

a plurality of resource objects and policy objects for defining the first and second policy settings. 

47. The system of claim 46, wherein the central database and the first and second 
databases are Lightweight Directory Access Protocol (LDAP) databases storing each resource 

20 object and policy object as an LDAP entry. 

48. The system of claim 46, wherein the resource objects are selected from a group 
consisting of devices, users, hosts, services, and time. 

25 49. The system of claim 48, wherein the devices include the first and second edge 

devices, each device being associated with a set of users and a particular host. 

50. The system of claim 48, wherein the hosts include the first and second networks, 

30 51. The system of claim 46, wherein the policy objects are selected from a group 

consisting of bandwidth, firewall, administration, and virtual private network grouping. 

52. The system of claim 5 1 , wherein the virtual private network grouping includes a 
virtual private network associated with one or more sites, users, and rules. 



35 



53. The system of claim 52, wherein each site includes one or more networks behind 
an edge device. 
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1 54. The system of tiaim 52, wherein the rules are firewall ruJes providing access 

control over network traffic flowing through the virtual private network. 

55. A system for selective database synchronization comprising: 

5 a central database storing configuration information for a plurality of edgetievices in an 

organization, each edge device being associated with a network in the organization and 
configured to manage policies for the network; 

a subordinate database storing a portion of the configuration information associated v^th 
a particular edge device; and 
10 a central policy server in communication with the central database and the subordinate 

database, the central policy server including logic for: 

making a change to the portion of the configuration information associated with the 
particular edge device in the central database; 

creating a log of the changes; 
1 5 storing the log in the central database; and 

transferring the changes to the particular edge device for updating the subordinate 

database. 

56. The system of claim 55, wherein the log includes a user log for associating the 
20 change to a particular user making the change, the particular user being associated with the 

particular edge device. 

57. The system of claim 56. wherein the central policy server further includes logic for 
identifying the particular edge device based on the particular user making the change. 



25 



58 . The system of claim 57, wherein the log includes a device log for storing the change 
for the particular edge device. 



59. The system of claim 55, wherein the central policy server further includes logic for: 
30 receiving a status of the transfer fi-om the particular edge device; and 

deleting the log from the central database if the status indicates a successful transfer. 

60. The system of claim 55, wherein the central database and the subordinate database 
are Lightweight Directory Access Protocol (LDAP) databases storing configuration information 

35 as an LDAP enuy identified by a distinguished name. 

61. The system of claim 55, wherein the configuration information is policy 
management information. 
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1 62. In a system including a first edge device managing policies for a first network 

according to first policy settings and a second edge device managing policies for a second 
network according to second policy settings, the system further including a central policy server 
in communication with the first and second edge devices configured to define the first and second 
5 policy settings and manage the first and second edge devices firom a single location, each-edge 
device comprising: 

a classification engine for determining a protocol associated with an incoming packet; 
a policy engine for making a forwarding decision for the packet based on policy settings 
associated with tlie packet: and 
1 0 a packet forwarding module for forwarding the packet based on the policy settings. 

63. The edge device of claim 62. wherein the classification engine further includes a 
protocol database storing a mapping of protocols to data patterns found in a packet stream. 

J 5 64 . The edge device of claim 62, wherein the policy engine further includes a resource 

engine with a current mapping of resource group names to members in each group. 

65. The edge device of claim 64, wherein the policy engine further includes a policy 
rules buffer storing policy settings specified for a group associated with the packet. 

20 • . 

66. The edge device of claim 64, wherein the policy engine further includes a decision 

engine for matching the packet with the policy settings in the policy rules buffer based on 
membership information from the resource engine. 

25 67. The edge device of claim 62 further including a security engine for authenticating 

a user transmitting the packet. 

68. The edge device of claim 62 further including a statistics module for collecting 
statistics on packets flowing through the edge device. 

30 

69. The system of claim 68, wherein the statistics module maintains a byte count of the 
packets flowing through the edge device, wherein the byte count is organized according to 
resources associated with the packets. 

35 70. A computer network comprising: 

a first edge device coupled to a first private network, the first edge device configured to 
create a first table with information of member networks reachable through the first edge device, 
the first table being stored in a first database; 
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1 a second edge device coupled to a second private network, the second -edge device 

configured to create a second table with information of member networks reachable through the 
second edge device, the second table being stored in a second database; 

wherein, the first and second edge devices enable secure communication between the first 

5 and second private networks, and the first edge device shares the first table with the second edge 
device and the second edge device-sharesahe second table with the first edge device. 

71 . The computer network of claim 70, wherein the first edge device includes logic 
receiving a new route information; 

storing the new route information in the first database; and 
transmitting a portion of the new route information to the second edge device. 

72. Tlie computer network of claim 71, wherein the portion of the new route 
15 information is a route name. 

73 . The computer network of claim 7 1 , wherein the second edge device includes logic 

for: 

receiving the portion of the new route information; 
20 accessing the first database based on the portion of the new route information; 

retrieving the new route information from the first database; and 
storing the retrieved route information in the second database. 

74. The computer network of claim 70, wherein communication between the first and 
25 second networks is managed according to a security policy associated with the networks. 

75. The computer network of claim 74, wherein the security policy is defined for a 
security group providing a hierarchical organization of the group, the group including member 
networks, users allowed to access the member networks, and a rule controlling access to the 

30 member networks. 

76. The computer network of claim 75, wherein each member network has full 
cormectivity with all other member networks and the security policy defined for the -security 
policy group is automatically configured for each connection. 

35 

77. The computer network of claim 75. wherein the security policy provides 
encryption of u-affic among the member networks and the rule is a firewall rule providing access 
control of the encrypted traffic among the member networks. 



for: 

10 
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1 78. A computer network <:omprising: 

an edge device coupled to a private network, the edge device ccwifigur^ to create a <able 
with information of member networks reachable through the edge device, the table being stored 
in a database; 

5 a remote user terminal in communication with the edge device, the remote user terminal 

including a processor, the processor being operable to execute program instructions, the program 
instructions including; ' 

establishing communication with the edge device; 
transmitting authentication information to the^dge device; and 
10 receiving the table with the information of the member networks from the edge 

device. 

79. The computer network of claim 78, wherein the program instructions further 
include automatically receiving updates of the table from the^dge device. 

15 

80. The computer network of claim 78, wher-ein the program instructions further 
include downloading a client software for installation and execution. 

81. The computer network of claim 80, wherein the client software allows 
20 communication with the member networks reachable through the edge device. 

82. The computer network of claim 80, wherein the client software allows the 
downloading of the table with the information of the member networks. 

25 83. The computer network of claim 80, wherein the client software includes a static 

portion and a dynamic portion, the static portion including an executable setup file and the 
dynamic portion including a template for being replaced with information specific to the 
downloading remote user terminal. 

30 84. The computer network of claim 80, wherein the dynamic portion is replaced with 

the table from the edge device v^th the information of the member networks. 

85. A system for managing policy services in an organization, the organization 
including a first network having a first set of resources and a second network remote from the 
35 first network having a second set of resources, the system comprising: 

a first edge device associated with the first network, the first «dge device configured to 
manage policies for the first network and the first set of resources in accordance with first policy 
settings stored in a first database; 
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1 a second edge device associated with the second network, the second edge device 

configured to manage policies for the second network and the second set of resources in 
accordance with second policy settings stored in a second database; and 

a central policy server in communication with the first and second edge devices, the 

5 central policy server configured to define the first and second policy settings and monitor health 
and status of the first and second edge devices from a single location. 

86. The system of claim 85, wherein the central policy server includes: 

a log collecting and archiving module for periodically receiving health and status 
10 information from each of the edge devices; 

an archive database coupled to the log collecting and archiving module for storing the 
health and status information; and 

a reports module coupled to the archive database for creating reports based on the health 
and status information. 

15 

87. The system of claim 86, wherein each edge device collects and transmits health 
and status information in a predefined common log fomiat. 

88. The system of claim 86, wherein the health and status information includes 
20 network flow information of packets flowing through the edge device. 

89. The system of claim 88, wherein the each edge device maintains a byte coimt of 
the packets flowing through the edge device, wherein the byte count is organized according to 
resources associated with the packets. 

25 

90. The system of claim 86, wherein the health and status information includes 
statistics on use of each edge device's set of resources. 

91. The system of claim 90, wherein the reports indicate usage of the resources 
30 associated with a particular edge device over a period of time. 

92. The system of claim 86, wherein the central policy server further includes means 
for determining when each of the edge devices is to transfer the health and -status information to 
the log collecting and archiving module. 

35 

93. A high-availability system comprising: 

a first edge device managing policies of a first network; 

a second edge device managing policies of a second network; and 
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1 a ceniral policy server in communicaiion witli the first and second edge devices, the 

central policy server managing the first and second edge devices from a single location; 

wherein, the central policy server and the first and second edge devices include fiist class 
units and second class units, each second class unit providing backup for a coiresponding first 
5 class unit upon failure of the first class unit. 

94. The system of claim 93', wherein each of the second class units is initially in an 
inactive state, each of the second class units including logic for: 

detecting a failure of a corresponding first class unit; and 
10 transitioning fi-om the inactive state to an active state upon detection of the failure. 

95. The system of claim 93, wherein each of the second class units includes logic for: 
assuming a role of the second class unit; 

searching for the corresponding first class unit; and 
15 initializing as the second class unit if the corresponding first class unit is detected. 

96. The system of claim 95, wherein each of the second class units ftuther includes 
logic for: 

assuming a role of the first class unit if the first class unit is not detected; 
20 searching for a corresponding second class unit; and 

initializing as the first class unit if the corresponding second class unit is detected. 

97. The system of claim 96, wherein each of the second class units further includes 
logic for initializing as a third class unit if the corresponding second class unit is not detected. 

25 

98. The system of claim 93 further comprising: 

means for transitioning each of the first class units to an active state; 
means for receiving and storing first database configuration changes for^ach of the first 
30 class units; 

means for transferring the configuration changes to the corresponding second class units; 



and 



means for storing the configuration changes on the corresponding second class units. 



35 99. The system of claim 98 ftmher comprising: 

means for transitioning each of the first class units to an inactive state; 
means for receiving and storing second database configuration changes for the second 
class unit while the corresponding first class unit is in the inactive state; and 
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means lor transferring the second -database configuration changes from the isecond class 
unit to the first class unit after the first class unit re-transitions to the active state. 



1 00. The system of claim 93 further comprising: 

5 means for transmitting update information to each of the first class units; 

means for updating each of the first class units; 

means for transmitting the update information from each of the first class units to each 
ol' the second class units: and 

means for updating each of the second class units. 

10 

101. In a system including a first network having a first sei of resources and a second 
network remote from the first network having a second set of resources, the first network being 
associated w ith a first edge device and a first database, and the second network being associated 
Willi a second cdijc device and a second database, the system further including a central policy 

1 5 server in comnuinicaiion with the first and second edge devices, a method for managing policy 
services in the s\ stem comprising: 

storing first policy settings in the first database; 
storing second policy settings in the second database; 

managing policies for the first network and the first set of resources fi-om the first edge 
20 device in accordance with the first policy settings stored in the first database; 

managing polic ies for the second network and the second set of resources from the second 
edge de\'ice in accordance with the second policy settings stored in the second database; and 

defining the first and second policy settings and managing the first and second edge 
devices from the central policy server from a single location. 

25 

102. The method of claim 101, wherein the policies are firewall policies. 

1 03. The method of claim 101 , wherein the policies are virtual private network policies. 

30 104. The method of claim 101, wherein the central policy server includes a central 

database and the method further comprises storing configuration information of the first and 
second edge devices in the central database. 

1 05. The method of claim 1 04, wherein the configuration information includes the first 
35 and second policy senings. 

106. The method of claim 104 further comprising: 

making changes to the configuration information of the first and second edge devices; and 
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1 07. The method of claim 1 06 further comprising transmitting the log x>f the changes 
to the first and second edge devices for respectively updating the First and second databases. 

5 

1 08- The method of claim 1 07 further comprising deleting the log of changes from the 
central database upon a successful update of the first and second databases. 

109. The method of claim 1 04, wherein the central database and the first and second 
10 databases are organized according to a hierarchical object oriented structure. 

110. The method of claim 109, wherein the hierarchical object oriented structure 
includes a plurality of resource objects and policy objects for defining the first and second policy 
settings. 

15 

111. The method of claim 1 1 0, wherein the resource objects are selected ft-om a group 
consisting of devices, users, hosts, services, and time. 

1 12. The method of claim 1 1 0, wherein the central database and the first and second 
20 databases are Lightweight Directory Access Protocol (LDAP) databases storing each resource 

object and policy object as an LDAP entry. 

113. The method of claim 1 0 1 further comprising installing the first and second edge 
devices from the cenu-al policy server. 

25 

1 1 4. The method of claim 1 0 1 further comprising registering the first and second edge 
devices with the central policy server. 

115. The method of claim 101 further comprising monitoring health and status of the 
30 first and second edge devices from the central policy server. 

1 16. The method of claim 101 further comprising: 

periodically receiving health and status information fi-om each of the edge devices; 
storing the health and status information in an archive database; and 
35 creating reports based on the health and status information. 

1 1 7. The method of claim 1 1 6, wherein each edge device collects and transmits health 
and status information in a predefined common log format. 
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1 118. The method of claim 116. wherein the health and status information includes 

network flow information. 

119. The method of claim 1 16, wherein the health and status information includes 
3 statistics on use of each edge device's-set of resources. 

120. The method of claim lOK wherein each edge device includes a classification 
engine, a policy engine, and a packet forwarding engine for integrating management of the 
policies into the edge device, and the managing of the policies for each of the networks further 

1 0 includes: 

determining a protocol associated with an incoming packet using the classification engine; 
making a forwarding decision for the packet based on policy settings associat-ed with the 
packet using the policy engine; and 

forwarding the packet based on the policy settings using the packet forwarding module. 

15 

121 . The method of claim 120, wherein each edge device includes a security engine 
and the managing of the policies for each of the networks further includes authenticating a user 
iransmiuing the packet. 

20 1 22. The method of claim 1 20, wherein each edge device includes a statistics module 

and the managing of the policies for each of the networks further includes collecting statistics on 
packets flov^ng through the edge device. 

123. The method of claim 101, wherein each network is a private network and each 
25 edge device is configured to create a table with information of member networks reachable 

through the edge device. 

1 24. The method of claim 1 23, wherein the first and second edge devices enable secure 
communication between the first and second private networks, and the method further comprises: 

30 sharing the first table with the second edge device; and 

sharing the second table with the first edge device. 

125. The method of claim 123 further comprising: 
receiving a new route information; 

35 storing the new route information in the first database; and 

transmitting a portion of the new route information to the second edge device. 
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126. The method of claim 123, wlierein the communication is managed according to 
a security policy associated with the member networks. 



127. The method of claim 126, further comprising defining the security policy for a 
5 security policy group, the group providing a hierarchical organization of the group including 

member networks, users allowed to access the member networks, and a rule controlling access 
to the member networks. 

1 28. The method of claim 1 27. wherein each member network has full connectivity 
1 0 with all other member networks, and the method further comprises automatically configuring the 

security policy defined for the security policy group for each connection. 

12^>. The method of claim 127. wherein the security policy provides encryption of 
ira! lie anu>nsj: the member networks and the rule is a firewall rule providing access control of the 
1 5 encry pted traffic among the member networks. 

130. The method of claim 127, wherein the system further includes a remote user 
terminal for accessing the member networks form a remote location, the method further 
comprising: 

20 establishing communication with the remote terminal; 

receiving authentication infomiation from the remote terminal; and 

transmitting to the remote terminal the table with the dynamic membership information. 

131. The method of claim 1 30 further comprising automatically U^nsmitting updates 
25 ol'ihe table to the remote terminal. 

132. The method of claim lOL wherein the central policy server and the first and 
second edge devices include first class units and second class units, each second class imit 
providing backup for a corresponding first class unit upon failure of the first class unit. 

30 

133. The method of claim 1 32, wherein each of the second class units is initially in an 
inactive state, and the method further comprises: 

detecting a failure of a corresponding first class unit; and 

transitioning the second class unit from the inactive state to an active state upon detection 
35 of the failure. 

134. The method of claim 132 further comprising initializing each unit, wherein the 
initialization includes: 
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assigning to the unit a role of the second class unit; 
searching for the corresponding first class unit; and 

initializing the unit as the second class unit if the corresponding first class unit is detected. 

135. The method of claim 134 further comprising: 

assigning to the unit a role of the first class unit if the first class unit is not detected; 
searching for a corresponding second class unit; and 

initializing the unit as the first class unit if the corresponding second class unit is detected. 

1 36. The method of claim 1 35 fiirther comprising initializing the unit as a third class 
unit if the corresponding second class unit is not detected. 



137. The method of claim 132 further comprising: 
transitioning each of the first class units to an active state; 

1 5 receiving and storing first database configuration changes for each of the first class units; 

transferring the configuration changes to the corresponding second class units; and 
storing the configuration changes on the corresponding second class units. 

1 38. The method of claim 1 37 further comprising: 

20 transitioning each of the first class units to an inactive state; 

receiving and storing second database configuration changes for the second class unit 
while the corresponding first class unit is in the inactive state; and 

transferring the second database configuration changes from the second class unit to the 
first class unit after the first class unit re-transitions to the active slate. 

25 

1 39. The method of claim 1 32 further comprising: 
transmitting update information to each of the first class units; 
updating each of the first class units; 

transmitting the update information from each of the first class units to each of the second 

30 class units: and 

updating each of the second class units. 

1 40. In a system including a first network having a first set of resources and a second 
network remote from the first network having a second set of resources, the first network being 

35 associated with a first edge device and a first database: and the second network being associated 
with a second edge device and a second database, the system further including a central policy 
server in communication with the first and second edge devices, the central policy server being 
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1 associated with a cental database, a method for managing policy services in the system 

comprising: 

storing configuration information of the first and second edge devices in the 
central database, the central database being organized in a hierarchical object oriented structure; 
s storing first policy settings in the first database; 

storing second policy settings in the second database; 

managing policies for thd first network and the first set of resources from the first 
edge device in accordance with the first policy settings stored in the first database; 

managing policies for the second network and the second set of resources from 
10 the second edge device in accordance with the second policy settings stored in the second 
database; and 

defining the first and second policy settings and managing the first and second 
edge devices from the central policy server. 

15 141. The method of claim 1 40, wherein the first and second databases are organized 

according to the hierarchical object oriented structure. 

1 42. The method of claim 1 40, wherein the configuration information includes the first 
and second policy settings. 

20 

143. The method of claim 142, wherein the hierarchical object oriented structure 
includes a pluralii\ of resource objects and policy objects for defining the first and second policy 
senings. 

25 1 44. The method of claim 1 43, wherein the central database and the first and second 

databases are Lightweight Directory Access Protocol (LDAP) databases storing each resource 
object and policy object as an LDAP entry. 

145, The method of claim 1 43, wherein the resource objects are selected from a group 
30 consisting of devices, users, hosts, services, and time. 

146. The method of claim 145, wherein the devices include the first and second edge 
devices, each device being associated with a set of users and a particular host. 

35 147. The method of claim 1 45, wherein the hosts include the first and second networks. 

148. The method of claim 143, wherein the policy objects are selected from a group 
consisting of bandwidth, firewall, administration, and virtual private network grouping. 
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1 149. The method of claim 148, wliereinthe virtual private network grouping includes 

a virtual private network associated with one or more sites, users, and rules. 

150. Tlie method of claim 1 49, wherein each site includes one or more networks behind 
'5 an edge device. 

151. The method of claim 149, wherein the rules are firewall rules providing access 
control over network traffic flowing through the virtual private network. 

10 152, A method for selective database synchronization comprising: 

storing in a central database configuration information for a plurality of edge devices in 
an organization, each edge device being associated with a network in the organization and 
configured to manage policies for the network; 

storing in a subordinate database a portion of the configuration information associated 
1 5 with a particular edge device; and 

making a change to the portion of the configuration information associated with the 
particular edge device in the central database; 
creating a log of the changes; 
storing the log in the central database; 
20 transferring the changes to the particular edge device; and 

updating the subordinate database based on the changes. 

153. The method of claim 152, wherein creating the log of the changes further 
comprises creating a user log for associating the change to a particular user making the change* 

25 the particular user being associated with the particular edge device. 

1 54. The method of claim 1 53 further comprising identifying the particular edge device 
based on the particular user making the change. 

30 155. The method of claim 154, wherein the creating the log of changes further 

comprises creating a device log for storing the change for the particular edge device. 

1 56. The method of claim 1 52 further comprising: 
receiving a status of the transfer from the particular edge device; and 
35 deleting the log from the central database if the status indicates a successful transfer. 
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1 157. The method of claim 152, wherein the central "database and the subordinate 

database are Lightweight Directory Access Protocol (LDAP) databases storing configuration 
information as an LDAP entry identified by a distinguished name. 

5 158. The method of claim 152, wherein the configuration information is policy 

management information. 

159. In a system including a first edge device managing policies for a first network 
according to first policy settings and a second edge device managing policies for a second 

1 0 network according to second policy settings, the system further including a central policy server 
in communication with the first and second edge devices configured to define the first and second 
policy settings and manage the first and second edge devices from a single location, a method for 
integrated policy management comprising: 

determining a protocol associated with an incoming packet; 

1 5 making a forwarding decision for the packet based on policy settings associated with the packet; 
and 

forwarding the packet based on the policy settings. 

1 60. The method of claim 1 59, wherein the determining further comprises: 

20 storing in a protocol database a mapping of protocols to data patterns found in a packet 

stream; and 

matching the packet to a protocol stored in the protocol database. 

161. The method of claim 1 59 further comprising maintaining in a resource engine a 
25 current mapping of resource group names to members in each group. 

162. The method of claim 161 further comprising storing in a policy buffer policy 
settings specified for a group associated with the packet. 

30 1 63 . The method of claim 1 62, further comprising matching the packet v^th the policy 

settings in the policy rules buffer based on membership information from the resource engine. 



1 64. The method of claim 1 59 further comprising authenticating a user transmitting the 

35 packet. 

165. The method of claim 159 further comprising collecting statistics on packets 
flowing through the edge device. 
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1 1 66. The method of claim 1 65, wherein the coilecting iiinher comprises: 

maintaining a byte count of the packets flowing through ^e edge device; and 
organizing ilie byie count according to resources associated with the packets. 

5 167. In a computer network including a first edge device coupled to a first private 

network and a second edge device coupled to a second private network, the first and second edge 
devices enabling secure communication between the first and second private networks, a method 
for gathering membership information comprising: 

creating a first table with inforaiation of member networks reachable through the first 
10 edge device; 

storing the first table in a first database; 

creating a second table with information of member networks reachable through the 
second edge device; 

storing the second table in a second database; 
1 5 sharing the first table with the second edge device; and 

sharing the second table with the first edge device. 

168. The method of claim 167 further comprising: 
receiving a new route information; 

20 storing the new route information in the first database; and 

transmitting a portion of the new route information to the second edge device. 

169. The method of claim 168, wherein the portion of the new route information is a 
route name. 

25 

170. The method of claim 168 further comprising: 
receiving the portion of the new route information; 

accessing the first database based on the portion of the new route information; 
retrieving the new route information from the first database; and 
30 storing the retrieved route information in the second database. 

171. The method of claim 1 67, wherein communication between the first and second 
networks is managed according to a security policy associated v^th the networks. 

35 172. The method of claim 171 further comprising defining the security policy for a 

security policy group, the group providing a hierarchical organization of the group including 
member networks, users allowed to access the member networks, and a rule controlling access 
to the member networks. 
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1 173. The method of claim 172, wherein each member network has full connectivity 

with all other member networks and the security policy defined for the security policy group is 
automatically configured for^ach connection. 

5 174. The method of claim 172, wherein the security policy provides encryption of 

traffic among the member networks and the rule is a firewall rule providing access control of the 
encrypted traffic among the member networks. 

1 75. In a computer network including an edge device coupled to a private network, the 
1 0 edge device including a table with information of member networks reachable through the edge 
device, a method of providing information of the member networks to a remote user terminal, 
the method comprising: 

establishing communication with the edge device; 

transmitting authentication infomiation to the edge device; and 
1 5 downloading a client software for installation and execution on the remote user terminal, 

the client software allowing communication with the member networks reachable through the 
edge device, the client software further allowing downloading of the table with the information 
of the member networks. 

20 1 76. The method of claim 1 75 fijrther comprising automatically receiving updates of 

the table from the edge device. 

1 77. The method of claim 1 75, wherein the client software includes a static portion and 
a dynamic portion, the static portion including an executable setup file and the dynamic portion 

25 including a template for being replaced with information specific to the downloading remote user 
terminal, and the method further comprises replacing the dynamic portion with the table from the 
edge device with the information of the member networks, 

1 78. In a system including a first network having a first set of resources and a second 
30 network remote from the first network having a second set of resources, the first network being 

associated with a first edge device and a first database, and the second network being associated 
with a second edge device and a second database, the system further including a central policy 
server in communication with the first and second «dge devices, the central policy server being 
associated with a central database, a method for managing policy services in the system 
35 comprising: 

storing configuration information of the first and second edge devices in the -central 
database; 

storing first policy settings in the tirst database; 
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1 Storing second policy filings in ihe second database; 

managing policies for the first network and the first set of resources from the first edge 
device in accordance with the first policy settings stored in the first database: 

managing policies for the second network and the second set of resources from the second 
5 edge device in accordance with the second policy settings stored in the second database; and 
defining the first and second policy settings and monitoring health and status of the first 
and second edge devices from the central policy server. 

1 79. The method of claim 1 78, wherein the monitoring further comprises: 

1 0 periodically receiving health and status information from^ach of the edge devices; 

storing the health and status information in an archive database; and 
creating reports based on the health and status informr.tion. 

1 80. The method of claim 1 79, wherein each edge device collects and transmits health 
1 5 and status information in a predefined common log format. 

181. The method of claim 179, wherein the health and status information includes 
network flow information. 

20 1 82. The method of claim 181, further comprising: 

maintaining a byte count of the packets flowing through the edge device; and 
organizing the byte count according to resources associated with the packets. 

183. The method of claim 179, wherein the health and status information includes 
25 statistics on use of each edge device's set of resources. 

184. The method of claim 183, wherein the reports indicate usage of the resources 
associated with a particular edge device over a period of time. 

30 185. The method of claim 1 79, wherein the monitoring further comprises determining 

when each of the edge devices is to transfer the health and status information to the log collecting 
and archiving module. 

i86. In a system including a first edge device managing policies of a first network, a 
35 second edge device managing policies of a second network, and a central policy server in 
communication with the first and second edge devices, the central policy server managing the 
first and second edge devices from a single location, a method for avoiding a single point of 
failure in the central policy server and the first and second edge devices, the method comprising: 
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1 maintaining first class units for the central policy server and the Erst and second ^dge 

devices; 

maintaining second class units of the central policy server and the first and second edge 
devices, each of the second class units acting as a backup for a corresponding first class unit, each 
5 of the second class units being initially in an inactive state; 
detecting a failure of one of the first class units: and 

transitioning the corresponding backup unit from the inactive state to an active state upon 
, detection of the failure. 

]0 1 87. The method of claim 1 86 further comprising: 

assuming a role of the second class unit; 

searching for the corresponding first class unit; and 

initializing as the second class unit if the corresponding first class unit is detected. 

15 188. The method of claim 1 87 further comprising: 

assuming a role of the first class unit if the first class unit is not detected; 
searching for a corresponding second class unit; and 

initializing as the first class unit if the corresponding second class unit is detected. 

20 1 89. The method of claim 1 88 fiirther comprising initializing as a third class unit if the 

corresponding second class unit is not detected. 

1 90. The method of claim 1 86 further comprising: 
transitioning each of the first class units to an active state; 

25 receiving and storing first database configuration changes for each of the first class units; 

transferring the configuration changes to the corresponding second class units; and 
storing the configuration changes on the corresponding second class units. 

191. The method of claim 1 90 funher comprising: 

30 transitioning each of the first class units to an inactive state; 

receiving and storing second database configuration changes for the second class unit 
while the corresponding first class imit is in the inactive state; and 

transferring the second database configuration changes from the second class unit to the 
first class unit after the first class unit re-transitions to the active state. 



35 



1 92. The method of claim 1 86 further comprising: 
transmitting update information to each of the first class units; 
updating each of the first class units; 
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transmitting the update information from each of the first class units to each of the second 
class units; and 

updating each of the second class units. 
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